二、银行信息怎么给才不汇错、不退汇

更新于 2026/10/16讲清汇款所需字段、常见填写错误与后果、PI 中的呈现与防篡改要点，并给出收款信息发出前的自查核对清单。

适用场景

客户说”把你们的银行信息发我”，你随手复制一段发过去，心里不确定有没有漏项。
客户反馈”汇款被退回来了，说账户信息不对”，你才发现 SWIFT 或户名有出入。
公司账户变更过，你要给一批老客户同步新信息，但担心被误认为诈骗邮件。
客户问”我要不要填中间行”，你答不上来，只能让他自己问银行。

收款信息是整条 T/T 链条的输入端。输入端错一个字符，后面所有环节的努力都会归零——而且代价是退回重汇，通常要额外多等一到两周。这一篇解决的就是”把信息给对”。

开始前准备

向开户行索取一份正式版收款信息（通常叫”汇款路径”或”收款指引”），最好是银行出具或客户经理确认过的版本，包含受益人、银行、SWIFT/BIC、是否需中转行。
确认账户状态：账户币种是什么、能否收对应外币、是否为待核查账户、是否有收汇额度限制。
确认主体名称：收款人名称必须与银行账户登记名称完全一致，这是退汇最常见的原因。
准备 PI / 合同模板：银行信息最终要落在单据上，而不是只在聊天记录里飘着。

认知前提：收款信息不是一段”说明文字”，而是一组机器要逐字比对的字段。银行系统不会”猜你的意思”，户名少一个 Ltd.、账号多一横，都可能导致电文被拒或被挂起。所以给客户的信息必须结构化、可复制、不易改。

边界提示：不同银行、不同币种对字段的要求不完全相同，以开户行当期出具的收款指引为准；文中的账号、SWIFT、金额均为演示用虚拟示例，不可直接使用。

操作步骤或讲解

一、一笔 T/T 需要提供的字段

把下面这张表当作”最小完整集”来核对。缺项就意味着客户可能填错或银行可能退回。

字段	英文常用名	说明	是否必需
收款人名称	Beneficiary / Account Name	必须与账户登记名逐字一致	必需
收款人地址	Beneficiary Address	部分银行与国别要求	常见必需
收款账号／IBAN	Account Number / IBAN	欧洲等地以 IBAN 为准，须完整	必需
收款银行名称	Beneficiary Bank Name	银行全称，不用缩写	必需
收款银行地址	Bank Address	部分链路要求	常见必需
SWIFT／BIC	SWIFT Code / BIC	8 位或 11 位，决定电文怎么走	必需
中转行信息	Intermediary / Correspondent Bank	某些币种与链路需要	视情况
中转行 SWIFT	Intermediary SWIFT	与上一项配套	视情况
汇款用途	Purpose of Payment	合规审查要点	必需
参考号／附言	Reference / Remarks	写 PI 号，便于双方对账	强烈建议

一个判断口诀：谁收钱、收哪个号、哪个银行、哪个 SWIFT、怎么走。五个问题都能答，信息才算给全。

二、常见错误与后果

错误类型	典型表现	直接后果	修正成本
漏 SWIFT/BIC	只给了银行名称	汇出行无法路由，退回或长期挂起	高，需重新发起
户名不一致	用简称、漏掉 Ltd./Co., Ltd.、中英文混用	收款行拒收，退回	高
账号错位	数字少位、多空格、IBAN 不完整	电文被拒或误入他人账户	极高
缺中转行	该币种必经中转行却未给	款项在路上反复退回	中
币种与账户不匹配	用人民币账户收美元	到账后被退或需强制结汇流程	中
只发图片/截图	客户手工录入出错	隐性错误，事后才发现	高
信息分散在多条消息	客户漏抄其中一段	退回或错汇	高
用途填写模糊	合规审核卡住	延迟不可预测	中

重点提醒：户名与账号是两条独立的校验线，银行会同时比对。只对上一项不代表安全。发现被退回时，一定要让客户提供退回原因的电文原文，而不是猜。

三、给客户的呈现方式

信息给出后还要防”在传递中被改”。推荐三条做法：

一屏之内、结构化的纯文本，不用截图。截图无法复制、容易看错数字；文字可复制，但会被手工重敲。
字段名 + 值分行排列，例如：

Beneficiary Name : (演示示例) ABC TRADING CO., LTD.
Account Number   : (演示示例) XXXX-XXXX-XXXX
Bank Name        : (演示示例) XX BANK, XX BRANCH
SWIFT / BIC      : (演示示例) XXXXCNXX
Bank Address     : (演示示例) XX Road, XX City, China
Intermediary Bank: (演示示例) XX BANK, NEW YORK
Intermediary SWIFT: (演示示例) XXXXXXUS
Reference        : PI-2026-XXXX

在 PI 上同步固定：PI 中的银行信息应作为独立区块排版，与金额、产品并列，避免夹杂在说明文字里。

防篡改要点：

做法	作用
PI 输出为 PDF 而非可编辑文档	降低被篡改后再次流转的可能
银行信息旁注明”以我司盖章 PI 为准”	给客户一个官方核验基准
公司邮箱为唯一发送通道	减少冒名改单的空间
首次合作时在合同中写明账户信息	建立不可随意变更的书面基准
账户信息变更时走独立核实流程	见客户说”收款账户改了”，怎么判断是不是诈骗

四、发出前的自查核对清单

每次给客户发收款信息前，按顺序过一遍：

序号	检查项	通过标准
1	户名	与银行账户登记名逐字一致，含标点与后缀
2	账号／IBAN	位数正确、无多余空格、无缺位
3	SWIFT/BIC	8 位或 11 位，与开户行一致
4	银行名称与地址	使用银行全称，不写简称
5	中转行	按开户行指引确认是否需要，需要则两者齐全
6	币种匹配	客户汇款币种与账户可收币种一致
7	参考号	已附上 PI 号，便于对账
8	发送渠道	使用公司邮箱，非个人邮箱或社交工具
9	版本核对	与开户行最新指引一致，非旧版本
10	内部复核	由第二人复核一次账号与 SWIFT

五、一个退回案例的复盘（演示用虚拟数字）

某客户汇出 USD 8,800.00，一周后被退回，原因显示”Beneficiary name mismatch”。复盘发现：我方 PI 上写的是公司简称，银行账户登记名是含后缀的全称，客户照 PI 录入，收款行比对不通过。

这个案例的三个教训：

PI 上的名称必须与银行登记名一致，不要为了排版好看而简化；
退回不是”客户的问题”，而是我方输入端的问题；
每一次退回都是一到两周的时间成本，足以打乱交期。

判断标准

信息是否”合格”，用三条硬标准判断：

可比对：客户拿到后不需要做任何解释性判断，直接逐字录入即可。
可核验：客户能凭你给的基准（盖章 PI、公司邮箱原文）确认信息没被第三方改过。
可追溯：出现退回时，你能立刻定位是哪一项字段出了问题，而不是全面排查。

状态	判断	动作
五项核心字段齐全、与银行指引一致	合格	可以直接发送
缺少中转行信息但不确定是否需要	待确认	先问开户行，不要凭经验猜
客户已汇出后才发现字段有误	高风险	立即通知客户联系汇出行更正或退回，并同步我方银行
客户提出要改成另一家银行	需核实	走双重核实流程，绝不在邮件中直接确认

常见失败与修正

失败表现	根因	修正动作
每次都重新手打银行信息	没有标准模板	建立一份经银行确认的标准信息文本，长期复用
把银行信息写在邮件正文里随口一提	无固定格式	用结构化字段表，并同步到 PI
客户说”收到了”就以为没问题	未要求回读校验	让客户把录入的关键字段回读一遍再提交
用个人邮箱发送银行信息	渠道不规范	一律使用公司邮箱，并在合同中约定该渠道
银行账户变更后在群里通知一遍	变更流程缺失	建立变更专项流程，逐户电话核实并留档
收到退回后先怪客户	归因错误	先查我方 PI 与银行登记名是否一致

执行清单

向开户行索取并保存最新版收款指引（含中转行说明）。
建立公司标准收款信息模板，字段齐、纯文本、可复制。
核对 PI 中的收款人名称与银行登记名是否逐字一致。
每次发送前完成十项自查，并由第二人复核账号与 SWIFT。
首次合作订单在合同或盖章 PI 中固定账户信息，作为不可随意变更的基准。
客户汇款前，请其回读关键字段进行确认。
出现退回时，取得电文原文并归档，作为流程改进输入。

边界提示：本篇讲的是信息准备与呈现的方法。各银行对字段、格式、中转行的具体要求以开户行当期规定为准，文中账号与 SWIFT 均为演示用虚拟示例。款项在途后的流程与时序见 T/T 从打款到到账：中间经过哪些环节，客户凭证核实见客户发来水单，怎么核实真假。

下一篇：客户发来水单，怎么核实真假

下一步

把「银行信息怎么给才不汇错、不退汇」继续交给跨境支付 Agent

适合把支付方式选型、结算准备、合规核对和沟通说明整理成标准流程。

减少支付环节混乱让合规核对更可重复提升跨团队沟通效率

先看方案页继续到 Agent 站点

引用本文

引用时可保留文章名称、规范地址和页面记录的更新时间。

引用信息

TradeGoAI 外贸知识库，《银行信息怎么给才不汇错、不退汇》，更新于 2026-10-16。https://tradegoai.cn/kb/cross-border-payment/tt-operations/bank-info-writing/