SWIFT ACK 消息解析

Posted 2023-02-22

【中文标题】SWIFT ACK 消息解析

【英文标题】：SWIFT ACK Message Parsing

【发布时间】：2016-04-21 00:14:17

【问题描述】：

我正在通过基于 java 的应用程序生成 SWIFT 消息 MT 110 和 MT 103。为了与最终客户进行对账和共享，我们需要将从 SWIFT 终端收到的 Ack Nak 消息映射回 MT 110 和 MT 103 交易。为此，我需要解析每个 ACK​​ 文件并找出

20：发件人参考 ABC1380Q02418

451:0 (ACK)

451:1 (NAK) 然后是 405 字段。

我曾尝试使用 Prowide Core (WIFE) 开源 SWIFT Java 库执行此操作，但我无法解析 ACK。通过库，我能够解析 MT 110 和 MT 103 消息，但不能解析 ACK 或 NAK 消息。需要您帮助了解如何通过 Prowide Core (WIFE) 开源 SWIFT Java 库解析 SWIFT ACK NAK 文件。

下面粘贴的示例 ACK 消息：

23/12/15-11:50:14 BulBoardCTFACK-0192-000001 1

---

---------- 实例类型和传输 --------------

发送至 SWIFT (ACK) 的原始通知（传输）

网络传送状态：网络确认

优先级/交付：正常

消息输入参考：1150 151223ABCINBBADEL2567311531

--------------- 消息头 ------------------ -------

Swift 输入：FIN 103 单一客户信用转移

发件人：ABCDINBBDEL TTTT银行有限公司 (XXXX分行) YYYYYYYY YY

接收器：ANZBAU3MXXX 澳新银行集团有限公司 墨尔本澳大利亚

--------------- 消息文本 ------------------ ---------

20：发件人参考 ABC1380Q02418

23B：银行操作代码 信用

32A：Val Dte/Curr/Interbnk Settld Amt 日期：2015 年 12 月 23 日 货币：AUD（澳元） 金额：#8000,0#

33B：货币/指示金额 货币：AUD（澳元） 金额：#8000,0#

50K：订购客户名称和地址 /M4132378 ABC DEF GHI 76 AX , 模型镇 EXT , XXXXXXX

53A：发件人的通讯员 - FI BIC /1111111 00001 ABCDEFBBDEL ABC

57D：具有 Inst -Name & Addr 的帐户 //AU063144 共同财富银行 澳大利亚 SWIFT 代码 CTBAAU2S

59：受益人客户名称和地址 /555555 ABCDEF YYYYYYYY

70：汇款信息 维护

71A：收费详情 本

71F：寄件人的费用 货币：AUD（澳元） 金额：#0,0#

--------------- 消息尾 ------ ------

CHK:41B1AA23FEDF

PKI 签名：MAC 等效

---------------------------- 干预 ------ -------

类别：网络报告

创作时间：23/12/15 11:50:03

应用：SWIFT 接口

操作员：系统

文字

1:F21ABCDEFBBADEL25673115314:177:1512231150451:0

【问题讨论】：

嗨，你有没有找到任何 ACK/NACK 消息的解析器我发现的唯一有用的东西是 sepaforcorporates.com/swift-for-corporates/…

不，我没有找到任何库，我们已经开发了自己的代码。

我们也是。我已在 WIFE - Prowide Core sourceforge.net/p/wife/support-requests/18

上发布请求

【参考方案1】：

发布的示例是扩展打印输出，而不是 SWIFT FIN 格式的消息。但是，在最后一行称为“文本”的地方有 FIN 系统消息，可以由 Prowide Core 解析。

1:F21ABCDEFBBADEL25673115314:177:1512231150451:0

系统消息中的字段 451 指示消息是被确认 (0) 还是被确认 (1)。当 nacked 字段 405 将包含错误代码。例如：405:T33002

最常见的结构是带有 ACK/NAK 的系统消息，后跟原始消息的完整副本：

1:F21LITEBEBBAXXX00660000794:177:1104180901451:01:F01LITEBEBBAXXX00660000792:I999LITEBEBBXXXXN4:
:20:TESTREF1
:79:This is text line 1
-5:CHK:7602B010CF31TNG:

第一步是确定接收到的消息是否为 ACK/NAK。一旦消息被解析为 SwiftMessage，这个方法可以用来验证它是一个普通的 FIN 用户到用户的消息，还是一个带有 ACK/NAK 的系统消息

SwiftMessage.isSystemMessage()
SwiftMessage.isAck()
SwiftMessage.isNack()

第二步是将 ACK/NAK 信息从原始消息的标识中分离出来。此示例使用最常见的格式，即 ACK/NAK 消息后跟原始消息的完整副本（例如，SAA AFT 或 SA Lite 自动客户端使用的格式）。解析 ACK/NAK 和原始副本：

Swiftparser parser = new SwiftParser();
SwiftMessage ack = parser.parse(msg);
SwiftMessage original = parser.parse(ack.getUnparsedTexts().getAsFINString());

最后，要将 acked/nacked 消息与其原始消息匹配，必须对候选者进行查询（通常搜索同一天和相同消息类型的消息）。查找候选者不在库中，因为它涉及搜索应用程序数据库或从文件系统目录读取发送的消息。虽然，在候选人中，匹配可以这样完成：

AckMessageComparator comparator = new AckMessageComparator();
    for (SwiftMessage candidate : candidates) 
        if (comparator.compare(original, candidate) == 0) 
            //candidate is the message acked/nacked
        
    

根据确认通知源的不同，消息的结构可能会有所不同。例如，原始消息的完整副本可能会丢失。但是，必须存在对原始 acked/nacked 消息的其他类型的引用，例如 MUR（消息用户参考），如下所示：

1:F21LITEBEBBAXXX00660000794:177:1104180901451:0108:FOO16101900001

所以要匹配原始消息，而不是使用完整的消息副本和 AckMessageComparator，必须找到具有相同 MUR 的消息：

for (SwiftMessage candidate : candidates) 
        if (StringUtils.equals(ack.getMUR(), candidate.getMUR())) 
             candidate is the message acked/nacked
        
    

如果 ACK/NAK 中既不存在原始消息副本也不存在 MUR，则可能存在 UUID（唯一标识符），并且可以从 UUID 字段（如接收方地址、消息类型和引用）中匹配候选者。

ACK/NAK 必须以某种方式提供信息以正确匹配被确认的原始消息。

【参考方案2】：

ACK/NAK 通知使用服务 ID 21 进行标识。

您可以使用 Prowide Core 中的 ServiceMessage21 类来解析 Acks 和 Nacks

https://www.javadoc.io/doc/com.prowidesoftware/pw-swift-core/SRU2018-7.10.4