SWIFT ACK消息解析

时间:2016-01-15 11:49:54

标签: financial banking swift-mt

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

20:发件人参考 ABC1380Q02418

451:0(确认)

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 BANK LIMITED (XXXXX BRANCH) YYYYYYYYY YY

接收方:ANZBAU3MXXX 澳大利亚和新西兰银行集团有限公司 MELBOURNE AU

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

20:发件人参考 ABC1380Q02418

23B:银行营运守则 CRED

32A:Val Dte / Curr / Interbnk Settld Amt 日期:2015年12月23日 货币:澳元(澳大利亚元) 金额:#8000,0#

33B:货币/指示金额 货币:澳元(澳大利亚元) 金额:#8000,0#

50K:订购客户名称&地址 / M4132378 ABC DEF GHI 76 AX,MODEL TOWN EXT, XXXXXXXX

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

57D:使用Inst -Name&地址 // AU063144 共同财富银行 澳大利亚SWIFT CODE CTBAAU2S

59:受益人客户姓名&地址 / 555555 ABCDEF YYYYYYYYY

70:汇款信息 维护支持

71A:收费详情 BEN

71F:发件人的收费 货币:澳元(澳大利亚元) 金额:#0,0#

---------------------------消息预告片------------------ ------

{CHK:41B1AA23FEDF}

PKI签名:MAC-Equivalent

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

类别:网络报告

创作时间:2015年12月23日11:50:03

应用程序:SWIFT接口

运营商:SYSTEM

文本

{1:F21ABCDEFBBADEL2567311531} {4:{177:1512231150} {451:0}}

2 个答案:

答案 0 :(得分:2)

发布的样本是扩展打印输出,而不是SWIFT FIN格式的消息。但是,在称为“文本”的最后一行上,您有FIN系统消息,该消息可由Prowide Core解析。

{1:F21ABCDEFBBADEL2567311531}{4:{177:1512231150}{451:0}}

系统消息中的字段451指示消息是acked(0)还是nacked(1)。当nacked时,字段405将包含错误代码。例如:{405:T33002}

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

{1:F21LITEBEBBAXXX0066000079}{4:{177:1104180901}{451:0}}{1:F01LITEBEBBAXXX0066000079}{2:I999LITEBEBBXXXXN}{4:
:20:TESTREF1
:79:This is text line 1
-}{5:{CHK:7602B010CF31}{TNG:}}

第一步是确定收到的消息是否是ACK / NAK。一旦将消息解析为SwiftMessage,此方法可用于验证它是否是用户消息的常规FIN用户,或者是否是带有ACK / NAK的系统消息

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

第二步是将ACK / NAK信息从原始消息的标识中分离出来。此示例使用最常见的格式,即ACK / NAK消息,后跟原始消息的完整副本(例如,SAA AFT或SA Lite autoclient使用的格式)。要解析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:F21LITEBEBBAXXX0066000079}{4:{177:1104180901}{451:0}{108: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必须以某种方式提供信息,以正确匹配正在确认的原始邮件。

答案 1 :(得分:0)

ACK / NAK通知标识为服务ID 21。

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

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