Swiftnet fin error codes

swiftnet fin error codes

What information is available for the FIN messaging interface that SWIFT is offering? 13 FIN Error Codes Advance Information. Clarification, the error code C8 is used instead of B8 when sender BIC BIC NB: If a FIN message different from MT202 is received by ASI module. FIN is the native SWIFT message definition. The SWIFT standards describe more than 200 FIN message types. FIN Message types include user-to-user messages and.

Swiftnet fin error codes - situation familiar

1 Messaging FIN Error Codes This reference guide lists the error codes and abort notifications returned by FIN in case of message validation errors or other conditions such as protocol violations or delivery issues. 22 July 2016

2 FIN Table of Contents Preface... 4 About this document... 4 Audience... 4 Significant changes... 4 Chapter 1 Introduction... 5 Chapter 2 Numeric Codes General Logout/Quit Acknowledgement Errors Re-Login Request Errors Retrieval Errors Message Status Abort Reasons FIN and General Purpose Application Session Termination Report Errors Bulk Retrieval Errors Codes Chapter 3 Alphanumeric Codes General A Codes - Re-select Error Codes B Codes - Copy Service Errors C, D, and E Codes - Conditional Semantic Error Codes G Codes - Service-specific Validation H Codes - Basic Header and Application Header Validation K Codes - Code Words Validation in Generic Fields L Codes - LOGIN Errors M Codes - Message Errors N Codes - Market Infrastructure Resiliency Service (MIRS) Errors P Codes - Protocol Errors R Codes - Re-login/Re-select Errors S Codes - System-initiated Abort Errors S Codes - Select Errors T Codes - Text Validation U Codes - User Header Validation V Codes - System Message Errors and Message Block Format Errors Error Codes

3 Table of Contents 3.18 X Codes - FINCopy Message Validation (01-27) and Delayed NAK Error Codes (30-99) Y Codes - UNK Error Codes Z Codes - Trailer Validation Chapter 4 FIN Errors Introduction Abort Codes Diagnostic Codes for SS Diagnostic Codes for SA Legal Notices July

4 FIN Preface About this document Audience This reference guide lists the error codes and abort notifications returned by FIN in case of message validation errors or other conditions such as protocol violations or delivery issues. This book describes the FIN Error Codes. It should be read by: users who wish to gain an understanding of the FIN service developers who need background information on elements of FIN The reader is expected to have an understanding of FIN messaging, which is described in the FIN Service Description and the FIN Operations Guide. For more information about the rules, the reader must consult the Message Format Validation Rules. Significant changes The following tables list all significant changes to the content of FIN Error Codes since the 24 July 2015 edition. These tables do not include editorial changes that SWIFT makes to improve the usability and comprehension of the document. New information Addition of error codes E20, E88, E98, E99, T49, and T69 (no longer available) Addition of error code G27 Addition of error code U12 Location Error codes E20, E88, E98, E99, T49, and T69 G27 U12 Updated information Update text of error codes B05, C06, C08, C20, C28, C38, C39, C41, C71, C72, D07, D24, D31, D45, D59, D99, E04, E34, E39, E41, E42, E77, E78, E80, T09, T14, T22, T26, T39, T66, T94, T95, T96, U00, U09, X20, and X35 Location Section 3.3, B Codes - Copy Service Errors Section 3.4.1, C Error Codes Section 3.4.2, D Error Codes Section 3.4.3, E Error Codes Section 3.15, T Codes - Text Validation Section 3.16, U Codes - User Header Validation Section 3.18, X Codes - FINCopy Message Validation (01-27) and Delayed NAK Error Codes (30-99) 4 Error Codes

5 Chapter 1 Introduction Chapter 1 Introduction The FIN error codes are divided into the following groups: Validation error codes Conditional semantic error codes Abort error codes All input messages are validated for syntax and semantic errors by the system. If there is an error, a validation error code is returned in the logical (negative) acknowledgement or in an MT 019 Abort Notification. Abort error codes give the reason why an application or the logical connection has been discontinued. They are generated following the recognition of a certain condition and not necessarily due to errors in a message. Abort error codes can come from the system or from a user's terminal. For reference purposes, the error codes have been placed in two chapters. Chapter 2, Numeric Codes, contains all the errors that are represented by two- or three-digit codes. Error codes in Chapter 3, Alphanumeric Codes, have the following format: <code><nn> where <code> is a letter designating the error type and <nn> identifies the particular error. Where two or more variants of a message exist, for example, MT 103, MT 103 STP, and MT 103 REMIT, each variant is referenced independently in an error code description. This means that mention of the MT 103 refers only to the generic variant of the MT 103 and does not include either the MT 103 STP or the MT 103 REMIT. 22 July

6 FIN Chapter 2 Numeric Codes 2.1 General Numeric codes are used for: Logout/Quit Acknowledgement errors (field 401) Re-Login Request errors (fields 280, 331 and 333) Retrieval errors (field 421) Message status (field 431) Abort reasons (field 432) FIN and General Purpose Application session termination (field 443) Report errors (field 461) 2.2 Logout/Quit Acknowledgement Errors The following error codes are returned in field 401 of Logout and Quit acknowledgements. Logout and Quit Commands are always positively acknowledged and the session (General Purpose Application or FIN) closed. However, one of the following error codes can be included in the acknowledgement. 01 Incorrect time/day The Logout Command can include the time/day inhibitor which prevents the next Login occurring before the time/day specified. The time/day in the format DDHHMM cannot be more than 7 days after the current date. 02 Training trailer missing The trailer block is only present if the message is sent by a training logical terminal. If the Logout Command is sent from a training logical terminal, it must contain a Training trailer. 03 Input sequence number error Each message sent from a logical terminal has an input sequence number. The first message sent in the General Purpose Application will always have an input sequence number of , whereas the first message sent in FIN will have an input sequence number value of the last input sequence number+1 sent from that logical terminal. This error will be returned in the acknowledgement of a Logout or Quit Command when the input sequence number of that command is incorrect. 2.3 Re-Login Request Errors The following error codes are returned in fields 331, and 333 of acknowledgements, session history reports, and daily check reports: 010 Re-Login Request received while logical terminal is active on the Logical Terminal Control association 6 Error Codes

74 Retrieval Errors The following codes are returned in field 421 of message retrievals: 000 Message has no text block 002 Message was encrypted and no key or the wrong key was supplied by the user 22 July

8 FIN 003 Empty report (no messages found) 004 Logical terminal is not authorised to retrieve the message, that is the requester is neither the sender nor the receiver of the original message 005 Text lost due to Slice Processor recovery 006 History lost due to Slice Processor recovery 007 Target message is a retrieval report (MTs 021 or 023) 010 Invalid MT received by Slice Processor pseudo logical terminal (system) 011 Invalid <application-id> received by Slice Processor pseudo logical terminal (system) 012 Invalid date in retrieval criteria tag (system) 013 Invalid time in retrieval criteria tag (system) 014 End daytime before start daytime 015 Target message older than 124 days (for range retrieval, daytime used) 016 <branch-code> is not 'XXX' 018 Invalid destination for report (tag 102). The logical terminal must have the same destination as the sender of the retrieval request or be a SWIFT logical terminal, and must be enabled for the application in which the retrieval message is to be sent 019 Invalid input retrieval by receiver or output retrieval by sender (only single message input reference/message output reference allowed) 020 Invalid synonym retrieval (synonym is not sender or receiver of message) 021 Unknown target logical terminal 022 Request received at wrong Slice Processor (system) 023 Could not retrieve message input reference in message output reference retrieval (system) 032 No delivery attempt in message input reference retrieval by receiver 033 On-line text read error (system) 034 On-line history read error (system) 8 Error Codes

9 Chapter 2 Numeric Codes 035 Text read error from archival (system) 036 History read error from archival (system) 037 Partial report - major system recovery in progress 038 Unable to retrieve text and history from archival because of system problems 040 The limits for group retrieval (99 messages in one request) have been exceeded 041 Message could not be decrypted (system) 043 The logical terminals in the beginning message input reference/message output reference and the ending message input reference/message output reference in a range retrieval request are not the same, in tag 252 (message input reference range) or 254 (message output reference range) 044 Illogical use of field 152 <1st-isn> or field 153 <1st-osn>. input sequence number or output sequence number already included as component in message input reference(s) or message output reference(s) 045 Message text not retrievable (message not successfully delivered) 046 Off-line retrieval not allowed for Test and Training messages 047 The text of local test mode messages is not retrievable 048 Retrieval message too long 049 Retrieval period specified exceeds 10 days 099 Retrieval report problem. Contact your Customer Support Centre 2.5 Message Status The message status is returned in field 431 of non-delivery warnings, undelivered message reports, and retrieved messages. 01 Delivered 02 Rejected by destinee 04 Aborted 22 July

10Abort notification MT 019 contains an alphanumeric abort code 10 Error Codes

11 Chapter 2 Numeric Codes These codes are specific to each FINCopy service. Contact your respective service provider for the meaning of each code within the range For Euro Banking Association (EBA) Processing, only the following codes are used: 70 Refusal from the Clearing Computer, and delivery aborted; the Sender of the payment message should also receive an MT 998 / SMT n75 Error Message from the Clearing Computer giving further reasons for the refusal. 71 Refusal from the Clearing Computer because of a message format error that prevented normal processing, and delivery aborted. 99 System error 2.6 Abort Reasons The following codes are returned in field 432 of abort notifications and, for the FINCopy service, Message Refusals: 01 Message too old (remained undelivered for n days) 02 Too many unsuccessful delivery attempts 03 Destination disabled 04 Operator aborted 05 Message could not be recovered after a major system failure because it was user encrypted 06 Message type incompatible with the FIN interface mode 11 Message is too old, but was authorised 12 Too many delivery attempts, but message was authorised 13 Destination is disabled, but message was authorised 14 Message is too long, but was authorised 21 Message is too old and was bypassed 22 Too many delivery attempts and the message was bypassed 23 Destination is disabled and the message was bypassed 24 Message is too long and was bypassed 22 July

12 FIN 29 Message held for approval prior to Bypass mode and aborted 32 Message is too old and was not authorised 33 Copy message to the copy service server was aborted 35 FINCopy service parameter(s) incorrectly defined in FIN 50-ZZ 99 is pre-defined as 'system error'. All other alphanumeric codes (combination of 0-9 and A-Z) are specific to each FINCopy service. Contact your respective service provider for the meaning of each code. Code S1 is used by the Sanctions screening service to indicate that the message has been aborted on request of the subscribing user. Note: All undefined numeric codes are reserved for use by FIN. 2.7 FIN and General Purpose Application Session Termination The following codes are returned in field 443 of Service Message 14 (for further details see FIN System Messages): 000 Normal termination 001 Application Control or Logical Terminal Control has aborted 002 Application Control or Logical Terminal Control has terminated normally 004 System timed out message output reference ACK 006 QUIT or LOGOUT received while outstanding input messages 007 Input message/service message after reception of a QUIT or LOGOUT 008 Input window violation (more outstanding input messages than window size) 009 System timed out on association establishment 010 Reception of a SELECT from a logical terminal that already has a FIN session 011 Association establishment request failed authentication 014 Message output reference ACK Basic Header error 015 Too many messages input in a session. Maximum is Error Codes

13 Chapter 2 Numeric Codes 016 Too many messages output in a session. Maximum is Message output reference ACK from wrong synonym 025 As for 052 but due to receipt of a Re-Login Request, rather than a Login Request 051 As for 052 but on a different Regional Processor 052 Reception of a login from a logical terminal for which the system has already processed a login transmitted over a different Logical Terminal Control on the same Regional Processor. The existing session is aborted and the new session established. 053 SELECT with bad text block 054 AP ABORT REQUEST with bad text block 2.8 Report Errors The following codes are returned in field 461 of Delivery Subset Status Reports, Undelivered Message Reports, and Undelivered SSI Update Notification Reports: 001 Empty report 002 End of undelivered report 003 System undergoing major recovery or system not completely synchronised yet 004 Too many undelivered messages 005 User on fall back Regional Processor, cannot generate report 006 The message referenced in the request could not be found. 007 Invalid destination for report. The sender of the request must be the same as the sender of the message referenced in the request. 008 No MTs 671 were found for the referenced MT Requesting logical terminal in invalid state 016 Branch code is not "XXX' 099 System internal problems, contact your Customer Support Centre 22 July

14 FIN 2.9 Bulk Retrieval Errors Codes The following codes are returned in field 144 of Bulk Retrieval Responses (MT 025): 03 Retrieval only partially complete 11 Invalid <start-date-time> 12 Invalid <end-date-time> 13 Invalid retrieval time range 14 Retrieval aborted due to system error 15 Retrieval aborted due to communication error 16 Retrieval aborted due to system recovery 17 Retrieval aborted by SWIFT 19 Retrieval complete The text of messages that were sent to the retrieving BIC more than 124 days ago cannot be retrieved. If those messages were received by the retrieving BIC less than 124 days ago, the file contains the message output reference of the history and the message input reference of the text. 20 Retrieval aborted due to system error (Test and Training destination - attempt to use tape) 21 Retrieval aborted due to system error (FIN/FIN Bridge key error) 22 Retrieval aborted due to system error (missing master BIC) 14 Error Codes

15 Chapter 3 Alphanumeric Codes Chapter 3 Alphanumeric Codes 3.1 General This chapter contains the codes for the following error types: Code Error Type Code Error Type A Abort at Application Interface Level Errors P Protocol Errors A Re-select Errors R Re-login/Re-select Errors B Copy Service Errors S System-initiated Abort Errors C Dialout Errors S Select Errors C, D and E Conditional Semantic Errors T Text validation (Block 4) Errors G Service-specific Validation Errors U User Header Validation Errors H Basic Header and Application Header Validation Errors U User Abort Errors K Code Words Errors in Generic Fields V System Message or Message Block Format Errors L LOGIN Errors X Delayed NAK Errors and FINCopy Service Message Refusals M Message Errors Y User Negative Acknowledgement Errors N Market Infrastructure Resiliency Service (MIRS) Errors Z Trailer Validation Errors Note: Similar error codes are used by other SWIFT services, such as Accord, or Processing for Euro Banking Association (EBA), and can have different meanings. The error codes used by each of the services are described in the respective service documentation. 3.2 A Codes - Re-select Error Codes A56 Re-select NAK error code (in field tag 503) to indicate that the logical terminal is not in a recoverable state. The FIN interface should execute a fresh select procedure. 3.3 B Codes - Copy Service Errors B01 Message contains Value-Added Service server id but sender or receiver, or both, are not members of the service. B02 Available. B03 103:TPS is present in the message but the sender is not a member of TPS, or the message is not allowed for TPS. 22 July

16 FIN B04 Available. B05 A system error has occurred. Contact your local Customer Support Centre for further information. 3.4 C, D, and E Codes - Conditional Semantic Error Codes Note Where a natural language expression would be too difficult to synthesise or too long, a matrix is provided. The row and column headers identify the elements involved (for example, field tags, code words, letter options). Matrices should be read from left to right and from top to bottom C Error Codes C00 Not used. C01 MTs 102, 102 STP, 104, and 107 If field 19 is present in sequence C, then it must equal the sum of the amounts in all occurrences of field 32B in sequence B. MTs 201, 203, 204, and 559 The amount in field 19 must equal the sum of the amounts in all occurrences of field 32B or 34A. MT 256 If field 19 is present in sequence C, then it must equal the sum of the amounts in all occurrences of field 32J in sequence B. MT 824 Field 19 at the completion of each outer repetitive sequence must equal the sum of the products of subfields 1 and 3 in all occurrences of field 68A from its respective inner repetitive sequence(s). C02 The currency code must be the same for all occurrences of indicated fields in the entire message. See the Standards MT Message Reference Guides for the indicated fields in each message. Examples: The following list (not exhaustive) explains how error code C02 is applied in specific message types: MT 321. The currency code in the amount fields (fields 19A in sequence B) must be the same for all occurrences of this field in the message. MTs 320 and 330. The currency code in the amount fields, except for fields 33B and 33E in sequence G, must be the same for all occurrences of these fields in the message. MT 350. The currency code in the amount fields 32B and 34B in sequence B must be the same. 16 Error Codes

17 Chapter 3 Alphanumeric Codes Special Cases: The following MTs (not an exhaustive list) apply error code C02 in an exceptional manner (for example, either based on the presence of another field OR individually to separate groups of fields within the MT): MTs 103, 103 REMIT, and 103 STP. If field 71G is present, the currency code in the fields 71G and 32A must be the same. MTs 104 and 107. The currency code in fields 32B and 71 G in sequences B and C must be the same for all occurrences of these fields in the message. The currency code in field 71F in sequences B and C must be the same for all occurrences of this field in the message. MT 320. The currency codes in the amount fields 32B, 32H, and 34E in sequence B, and field 71F in sequence H, must be the same. MT 620. If field 32H is present, then the currency code must be the same as the currency code in field 32B. C03 The number of decimal digits in the amount component is checked against the maximum allowed for the corresponding currency. This check is mostly applied to fields that contain both the amount and the currency code components. Examples: field 32A in MTs 103, 103 REMIT, 103 STP and in MT 256, sequence C field 32B in MTs 104 and 107, sequences B and C This check also applies, among others, to: field 19 in MTs 102, 102 STP, 104, 107, 201, 203, 204, and 559 where the corresponding currency is the one used in field 32B or 34A field 19 in MT 824 where the corresponding currency is the one used in corresponding occurrences of field 68A field 32J in sequence B, and to field 19 in sequence C, in MT 256 where the corresponding currency is the one used in field 32A field 33B in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequence B field 71F in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequences B and C field 71G in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequences B and C field 72 Reject/Return in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequence A Note: Error code C03 should be applied only to field 68A in MT 824 if subfield 5 is present. C04 MTs 503, 504, and 506 In sequence B, if field :19B::TEXA is not present, then field :19B::TCRL is mandatory; otherwise field :19B::TCRL is optional. Sequence B If field :19B::TEXA is... Then field :19B::TCRL is July

18 FIN C05 Identifier Code must be a financial institution BIC. This error code applies to all types of BICs referenced in a FIN message, including connected BICs, non-connected BICs, Masters, Synonyms, Live destinations and Test & Training destinations. See the table below for the list of MTs affected. MT Field Sequence(s) Qualifier Comments A 56A 57A 52A A, B B B A, B 53A 54A 57A C C B The same validation applies to the MT 102 and the MT 102 STP A 53A 54A 55A 56A The same validation applies to the MT 103, MT 103 REMIT, and the MT 103 STP 57A A 53A 57A A, B C B Note: For sequence C, see also error code C A A, B 53A C 57A B A 53A 54A 111, A 200, , A 57A 52A 53A 54A 56A 57A 18 Error Codes

19 Chapter 3 Alphanumeric Codes MT Field Sequence(s) Qualifier Comments 58A 202 COV COV A 53A 54A 56A 57A 58A 52A 56A 57A 53A 57A 58A 52A 53A 56A 57A 58A 52A 53A 56A 57A 58A 52A 56A 57A 51A 52A 52G 56A 57A 58A A A A A A A B B B B A A A A A A A B B B A A A B B B A 22 July

20 FIN MT Field Sequence(s) Qualifier Comments 56A A C AJ 56AJ 57AJ 53AJ 56AJ 57AJ 53AJ 56AJ 57AJ 53A 56A 57A 53AJ 56AJ 57AJ 84AJ 86AJ B1, B2, D B1, B2, D B1, B2, D D1, D2, D3 D1, D2, D3 D1, D2, D3 B, E B, E B, E C, E, L C, E, L C, E, L B C, E, L P B3a CDEA INTE ACCW 95P D1 CDEA INTE ACCW AJ 56AJ 57AJ 86AJ C, D, E, F, I C, D, E, F, I C, D, E, F, I C, D, E, F, I P C1 CDEA INT2 INTE ACCW AJ 56AJ 57AJ 86AJ 53AJ 56AJ C, D, E, F C, D, E, F C, D, E, F C, D, E, F C, D, F C, D, F 20 Error Codes

21 Chapter 3 Alphanumeric Codes MT Field Sequence(s) Qualifier Comments 341, AJ 86AJ 53AJ 56AJ 57AJ 86AJ 53A 56A 57A 86A C, D, F C, D, F C C C C D, G, L, M D, G, L, M D, G, L, M D, G, L, M A D, G, K, L, M, N 56A D, G, K, L, M, N 57A D, G, K, L, M, N 86A D, G, K, L, M, N A 56A 57A 86A 53A 56A 57A 86A 53A 56A 57A 86A C, E C, E C, E C, E L, M L, M L, M L, M J, K, L, M J, K, L, M J, K, L, M J, K, L, M P B1 ACCW INT1 INT A 53A 54A 57A 22 July

22 FIN MT Field Sequence(s) Qualifier Comments 58A A A 450, 455, A P C2 ACCW INTM PAYE P C2a1, E1 ACCW INTM PAYE P B2a1, D1 ACCW INTM PAYE P B1b1 ACCW INTM PAYE P D2 ACCW INTM PAYE P C2 ACCW INTM PAYE P D2 ACCW INTM PAYE A B P C2 ACCW INTM PAYE 540, 541, 542, 543, 544, 545, 546, P E2 ACCW INTM PAYE A P D2a ACCW P E2 ACCW INTM PAYE A 56A 57A 86A 87A 53A 56A 57A 86A 87A 86A 87A B B, C B, C B, C B, C 22 Error Codes

23 Chapter 3 Alphanumeric Codes MT Field Sequence(s) Qualifier Comments A 87A A A 53AJ 56AJ 57AJ 86AJ C, D, E, F C, D, E, F C, D, E, F C, D, E, F A B, C A B A C P B1 ACCW INT1 INT A 42A 51A 53A 57A A 57A A A 42A 51A 52A 53A 57A A 42A 52A 57A 730, A A 22 July

24 FIN MT Field Sequence(s) Qualifier Comments 42A 58A A 57A 58A A A 54A A 57A 58A A 54A 768, A 51A 52A 53A 54A A A 53A 54A A A A 56A A n90 n91 52A 52A 57A C06 MT 210 Either field 50a or field 52a, but not both, must be present in a repetitive sequence. 24 Error Codes

25 Chapter 3 Alphanumeric Codes MTs 710 and 720 Either field 52a or field 50B, but not both, must be present. If field 52a is... Then field 50B is... MT 910 Either field 50a or field 52a must be present. C07 MT 516 Either field 35A or 35N must be present. C08 In fields listed below, the codes XAU, XAG, XPD, and XPT are not allowed, as these are codes for commodities for which the category 6 commodities messages must be used. MT Field Sequence(s) B B STP 32B 32A 32B 32A B C B C A 103 REMIT 32A 103 STP 32A A B A 202 COV 32A A B A 205 COV 32A A B B B B 33B 71F 32B B1 B2 C D B B1 22 July

26 FIN MT Field Sequence(s) B 32G 34B 32G 32B 33B 34a 34B 32B 33B 33E 32Q 32E 71F 32H B2 D D E A A A B1 D D E G H K L C09 MT 430 In each occurrence of sequence A, if field 33a is present, then field 32a must be present. C10 MT 422 At least one of the fields 72, 75 or 76 must be present. C11 MT 400 If field 57a is present, fields 53a and 54a must be present. C12 MTs 707 and 747 When field 32B or 33B is present, field 34B must be present. Conversely, when field 34B is present, either field 32B or field 33B must be present. C13 MT 750 If any of fields 33B, 71B, or 73 is present, field 34B must be present. C14 MTs 559 and 754 Either field 53a or 57a, but not both, may be present. C15 MT 747 At least one of the fields 31E, 32B, 33B, 34B, 39A, 39B, 39C, 72, or 77A must be present. 26 Error Codes

27 Chapter 3 Alphanumeric Codes C16 MT 707 If field 23 is present, field 52a must be present. C17 MT 734 If field 73 is present, field 33a must be present. C18 MT 752 If fields 32B and 71B are present, field 33a must be present. C19 MT 754 Either field 72 or field 77A, but not both, may be present. C20 MT 304 In sequence D, field 30F may only be present if field 34B is present. MT 601 Field 53a may be present only if field 34P is present. C21 MT 506 If sequence C is not present, then sequence D is mandatory. If one or more occurrence of sequence C is/are present, then sequence D is optional. If sequence C is... Then sequence D is... (once or more) C22 MT 920 If field 12 contains the value '942', at least field 34F Debit/(Debit and Credit) Floor Limit Indicator must be present in the same repetitive sequence. C23 MTs 920 and 942 When only one field 34F is present, subfield 2 must not be used. When both fields 34F are present, subfield 2 of the first 34F must contain D, and subfield 2 of the second 34F must contain C. In MT 920, this applies to each repetitive sequence. C24 MT 940 If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61. MT 942 If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61. Note: This rule does not apply for the field 86 if it is the last field in the message. When field 86 is the last field in the message and it is not preceded by a field 61, then it is considered to provide information about the message as a whole. 22 July

28 FIN C25 MT n92 Field 79 or a copy of at least any fields of the original message or both must be present. If field 79 is... Then copy of any field(s) of original message is... (that is, minimum one field, any field) Note: SWIFT does not validate the relationship between the copied fields and the original message, hence, any valid field is correct. The system will negatively acknowledge the MT n92 with error code C25 if there is no field after field 11S. C26 MT 430 At least one of the optional fields 32a or 74 must be present. C27 MTs 940, 941, 942, 950, 970, and 972 The first two characters of the three-character currency code in fields 60F, 60M, 62F, 62M, 64, 65, 90C, and 90D, in MTs 940, 941, 942, 950, 970 and 972, and field 34F in MT 942 must be the same for all occurrences of these fields. C28 MTs 541, 543, and 578 A value date must only be provided for cash/securities split settlement. That is, in any occurrence of subsequence E3, if value date field :98a::VALU is present, then in sequence E field :22F::STCO//SPST must be present, and settlement amount field :19A::SETT must be present in the same subsequence E3. In any occurrence of subsequence E3 if field :98a::VALU is... Sequence E then field :22F::STCO//SPST (with DSS not present) In the same occurrence of subsequence E3 and field :19A::SETT is... MTs 544, 545, 546, and 547 A value date must only be provided with an effective settlement amount, that is, in any occurrence of subsequence E3, if value date field :98a::VALU is present, then settled amount field :19A::ESTT must be present in the same subsequence. Subsequence E3 If field :98a::VALU is... Then field :19A::ESTT is... Note: MTs 544, 545, 546, and 547, see also error code E87. MTs 545 and 547, see also error code E Error Codes

29 Chapter 3 Alphanumeric Codes MT 586 A value date must only be provided for cash/securities split settlement. That is, in any occurrence of subsequence B5b, if value date field :98a::VALU is present, then in subsequence B5 field :22F::STCO//SPST must be present, and settlement amount field :19A::SETT must be present in the same subsequence B5b. In any occurrence of subsequence B5b if field :98a::VALU is... Subsequence B5 then field :22F::STCO//SPST (with DSS not present) is... In the same occurrence of subsequence B5b and field :19A::SETT is... C29 Available. C30 MT 707 At least one of the fields 31E, 32B, 33B, 34B, 39A, 39B, 39C, 44A, 44E, 44F, 44B, 44C, 44D, 79, or 72 must be present. C31 MTs n95 and n96 Either field 79 or a 'copy of any field(s) of the original message to which this message relates', but not both, may be present. Note: SWIFT does not validate the relationship between the copied fields and the original message; hence any valid fields are accepted. C32 MTs 300, 303, 304, 305, 306, 320, 330, 340, 341, 350, 360, 361, 362, 364, 365, 600, 601, 620, and 643 An optional sequence of fields was used. However, a field that is required (that is, indicated by an 'OR') or a field that is mandatory (that is, indicated by ' in...') within this sequence is missing. C33 MTs 768 and 769 If field 71B is present, field 32a must be present. C34 MT 769 Either field 33B or 39C, but not both, must be present. C35 MTs 643, 644, 646, and 649 Either field 21 or 29B must be present. C36 MTs 643 and 646 Subfield 2 (<DATE2>) of field 31F must be present in each occurrence of sequence B. C37 MT 577 Subfield 2 (<DATE2>) of field 67A must not be present. 22 July

30 FIN C38 MT 306 In sequence I, if field 12G contains the code BERM, then field 30T and field 22Y must be present. C39 MT 306 In sequence I, if field 12G contains the code AMER, then field 30Y must be present. C40 MT 920 The currency code must be the same for each occurrence of field 34F within each repetitive sequence. C41 MT 306 The presence of sequence J, subsequence J1, subsequence J2, and field 14B in sequence J depends on the value of field 12F in sequence A, as follows: Sequence A if field 12F is... Then sequence J is... Then subsequence J1 is... Then subsequence J2 is... Sequence J then field 14B is... AVRF AVRO AVSF AVSO DAVF DAVO Any other value Not applicable Not applicable Not applicable C42 MT 824 The currency code in each of the fields 68A of a sequence of fields 68A preceding a field 19 must be the same. C43 MT 646 Either field 32N or 33N must be present. C44 MT 646 If fields 32N and 33N are present in sequence C, field 34a must be present in sequence C. C45 MT 646 If field 23 contains REPRINC or PREPRINC, field 32N must be present in sequence C. C46 MT 646 If field 23 contains INT, field 33N must be present in sequence C. 30 Error Codes

31 Chapter 3 Alphanumeric Codes C47 MT 643 If field 23 contains LOAN/DRAWDOWN or FINARR/DRAWDOWN, sequence B must not be present. C48 MT 643 If field 23 contains LOAN/RENEWAL or FINARR/RENEWAL, sequence B must be present. C49 MT 456 If field 71B is present, the values in fields 32a and 33D must be different. C50 MTs 540, 541, 542, and 543 If field :36B: is present in minimum one occurrence of sequence A1, then the type of settlement transaction must be a pair-off or a turn-around, that is, sequence E field :22F::SETR//PAIR or :22F::SETR//TURN must be present. 1 if field :36B: is... Sequence E then field :22F::SETR must be... :22F::SETR//PAIR and DSS must not be present or :22F::SETR//TURN and DSS must not be present Not applicable C51 MT 643 If field 23 contains LOAN/DRAWDOWN or LOAN/RENEWAL, field 31R must be present. C52 MT 361 In sequence A, the presence of field 32B depends on field 23A, as follows: If field 23A is... Then field 32B is... CORRBUYER CORRSELLER VOLABUYER VOLASELLER Any other value C53 MT 643 If field 71C is present in any sequence B, field 34a must be present in the same sequence. C54 MT 644 Either field 36 or field 37(A-F) must be present in any sequence B. 22 July

32 FIN C55 MT 644 In any sequence B, the currency code in fields 33B and 34a must be the same. C56 MT 300 In sequence E, the presence of field 22Q depends on field 17Z as follows: Sequence E If field 17Z is... Then field 22Q is... Y N MTs 305 and 601 In sequence B, the presence of field 22Q depends on field 17Z as follows: Sequence B If field 17Z is... Then field 22Q is... Y N MT 306 In sequence M, the presence of field 22Q depends on field 17Z as follows: Sequence M If field 17Z is... Then field 22Q is... Y N MT 340 In sequence G, the presence of field 22Q depends on field 17Z as follows: Sequence G If field 17Z is... Then field 22Q is... Y N MTs 341 and 600 In sequence D, the presence of field 22Q depends on field 17Z as follows: 32 Error Codes

33 Chapter 3 Alphanumeric Codes Sequence D If field 17Z is... Then field 22Q is... Y N MT 360 In sequence O, the presence of field 22Q depends on field 17Z as follows: Sequence O If field 17Z is... Then field 22Q is... Y N MT 361 In sequence P, the presence of field 22Q depends on field 17Z, as follows: Sequence P If field 17Z is... Then field 22Q is... Y N C57 MT 646 If field 34N is present in any sequence B, field 31F in the same sequence B and field 33N in sequence C must be present. C58 MT 300 In field 77D of sequence A, if the code /VALD/ is present, then it must appear in the first 6 characters of the first line and in no other place, and it must be followed by a date expressed as YYYYMMDD and the "end_of_line" separator, that is, ":77D:/VALD/"YYYMMDD"CrLf". See also error code C59. MT 304 In field 72 of sequence C, if the code /VALD/ is present, then it must appear in the first 6 characters of the first line and in no other place, and it must be followed by a date expressed as YYYYMMDD and the "end_of_line" separator, that is ":72:/VALD/"YYYMMDD"CrLf". See also error code C59. MT 305 In field 72 of sequence A, if the code /VALD/ is present, then it must appear in the first 6 characters of the first line and in no other place, and it must be followed by a date expressed as YYYYMMDD and the "end_of_line" separator, that is ":72:/VALD/"YYYYMMDD"CrLf". See also error code C July

34 FIN MT 646 If field 34N is present in any sequence B, the total amount given in field 33N must equal the total amount of all occurrences of field 34N amounts in sequence B. C59 MT 300 In sequence A, if field 77D is present, then: if the first six (6) characters of the first line are equal to /VALD/, then the second line must be present and it must contain "/SETC/" in the first six (6) characters, followed by a valid ISO 4217 currency code and the end of line separator, that is, "/SETC/"<CUR>"CrLf". if the first six (6) characters of the second line are equal to /SETC/, then the first six (6) characters of the first line must be equal to /VALD/. the code "/SETC/" is not allowed in any other place than the first six (6) characters of the second line. if the first six (6) characters of the third line are equal to /SRCE/, then the first six (6) characters of the second line must be equal to "/SETC/". the code "/SRCE/" is not allowed in any other place than the first six (6) characters of the third line. See also error code C58. MT 304 In sequence C, if field 72 is present, then: if the first six (6) characters of the second line are equal to /SETC/, then it must be followed by a valid ISO 4217 currency code and the end of line separator, that is, "/SETC/"<CUR>"CrLf". if the first six (6) characters of the second line are equal to /SETC/, then the first six (6) characters of the first line must be equal to "/VALD/". the code "/SETC/" is not allowed in any other place than the first six (6) characters of the second line. if the first six (6) characters of the third line are equal to /SRCE/, then the first six (6) characters of the second line must be equal to "/SETC/". the code "/SRCE/" is not allowed in any other place than the first six (6) characters of the third line. See also error code C58. MT 305 In sequence A, if field 72 is present, then: MT 321 if the first six (6) characters of the first line are equal to /VALD/, then the second line must be present and it must contain "/SETC/" in the first six (6) characters, followed by a valid ISO 4217 currency code and the end of line separator, that is, "/SETC/"<CUR>"CrLf". if the first six (6) characters of the second line are equal to /SETC/, then the first six (6) characters of the first line must be equal to "/VALD/". the code "/SETC/" is not allowed in any other place than the first six (6) characters of the second line. In sequence B, the presence of field 19A and of the Next Interest Due Date (field :98A::INTR) depends on the Type of Loan/Deposit Event (field :22H::TLDE) in sequence A as follows: 34 Error Codes

35 Chapter 3 Alphanumeric Codes if field :22H::TLDE is... Then field :98A::INTR is... And field :19A::SETT is... Sequence B And field :19A::RODI is... And field :19A::CINT is... And field :19A::NINT is... CONF ROLL MATU MT 800 The amounts in fields 34B and 32A must be the same. C60 MT 307 In sequence A, the presence of field :22H::APER and the presence of field :22H::NEGR depends on the field :22H::CRTR as follows: If field :22H::CRTR is... Then field :22H::APER is... And field :22H::NEGR is... ASET AFWD MT 321 In sequence A, the presence of field :99B:: depends on the presence of field :22H::BLOC as follows: If field :22H::BLOC is... Then field :99B:: is... MT 643 In each sequence B, the currency code in fields 32P, 33a and 34a must be the same. C61 MT 307 In sequence A, the presence of field :22H::PAFI depends on field :22H::APER as follows: If field :22H::APER is... Then field :22H::PAFI is... OPEF NOPE Field :22H::APER not present MT 321 In sequence B, the presence of field :98A::LDFP depends on the value of field :22H::TLDE in sequence A as follows: 22 July

36 FIN if field :22H::TLDE is... Sequence B then field :98A::LDFP is... MATU Not MATU MT 643 In each sequence C, the currency code in fields 32B and 33B must be the same. C62 MT 307 The presence of sequence C depends on field :22H::APER as follows: if field :22H::APER is... Then sequence C is... OPEF NOPE Field :22H::APER not present MT 321 In sequence B, the presence of field :99B::DAAC depends on the presence of field :98A::LDFP as follows: Sequence B If field :98A::LDFP is... Then field :99B::DAAC is... C63 MT 307 In sequence A, the presence of the qualifier UNKN in field :22H::NEGR//UNKN depends on the content of field :22H::CRTR, of field :22H::APER and of field :22H::PAFI as follows: CRTR//ASET if field :22H:: is... CRTR//AFWD and APER//OPEF CRTR//AFWD and APER//NOPE and PAFI//PAIN CRTR//AFWD and APER//NOPE and PAFI//FINA Then field :22H::NEGR//UNKN is... MT 321 In sequence A, if field 99B is present, then all qualifiers must be present. C64 MT 307 The presence of sequence D depends on the value of field 22H as follows: 36 Error Codes

37 Chapter 3 Alphanumeric Codes If field :22H::CRTR is... And field :22H::APER is... And field :22H::PAFI is... And field :22H::NEGR is... Then sequence D is... ASET Not applicable per error code C60 Not applicable per error code C61 NETC ASET Not applicable per error code C60 Not applicable per error code C61 GRSC ASET Not applicable per error code C60 Not applicable per error code C61 AFWD OPEF Not applicable per error code C61 NETC or GRSC or UNKN AFWD NOPE PAIN NETC or GRSC or UNKN AFWD NOPE FINA NETC AFWD NOPE FINA GRSC C65 MT 567 If the message is a cancellation request status (:23G:CAST), then, in every occurrence of sequence A2 Status, a cancellation processing status must be reported (:25D::CPRC...). If the message is an instruction status (:23G:INST) then, in every occurrence of sequence A2 Status, an instruction processing status (:25D::IPRC...) must be reported. If the message is corporate action event processing status (:23G:EVST), then, in every occurrence of sequence A2 Status, an event status (:25D::EPRC...) must be reported. if field 23G is... Then, in every occurrence of sequence A2 field :25D must be... CAST INST EVST :25D::CPRC... :25D::IPRC... :25D::EPRC... C66 MT 643 The number of occurrences of sequence C must be equal to or greater than the number of occurrences of sequence B. C67 MT 516 In sequence A, either field 83C or 87a but not both, may be present. C68 MTs 202 COV and 205 COV In sequence B, if field 56a is present, then field 57a must also be present. 22 July

38 FIN C69 MT 507 In each occurrence of sequence B, if present, if subsequence B1 is present, the presence of subsequences B1a and B1b depends on the value of field :22H::COLL in sequence B as follows: Sequence B (each occurrence) If subsequence B1 is... And field :22H::COLL//Status is... Then subsequence B1a is... And subsequence B1b is... CCOL SCOL BCOL (Not applicable see also error code C70) Not applicable Not applicable Not applicable Not applicable Not applicable Note: Error code C70 takes precedence over error code C69. C70 MT 507 In each occurrence of sequence B, the presence of subsequence B1 depends on the value of fields :25D::COLL//<Status> and :22H::COLL//<Indicator> as follows: Sequence B (each occurrence) If field :25D::COLL/[8c]/4!c Data Source Scheme [8c] is... And field :25D::COLL/[8c]/4!c is... And field :22H::COLL//4!c is... Then subsequence B1 is... :25D::COLL//ACCT BCOL :25D::COLL//ACCT :25D::COLL//ACCT CCOL SCOL [1] [1] :25D::COLL//REJT Not applicable Not applicable BCOL CCOL [1] SCOL [1] [1] See also error code C69 for additional checks. Error code C70 takes precedence over error code C69. C71 MT 535 In each occurrence of subsequence B1, field :93B::AGGR cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. 38 Error Codes

39 Chapter 3 Alphanumeric Codes Subsequence B1 if field :93B::AGGR is... Repeated Then one occurrence of :93B::AGGR must be... :93B::AGGR//FAMT and DSS must not be present And the other occurrence of :93B::AGGR must be... :93B::AGGR//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 536 In each occurrence of subsequence B1a2, field :36B::PSTA cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B1a2 if field :36B::PSTA is... Then one occurrence of :36B::PSTA must be... And the other occurrence of :36B::PSTA must be... Repeated :36B::PSTA//FAMT :36B::PSTA//AMOR Not repeated Not applicable Not applicable MT 537 In each occurrence of subsequence B2b, field :36B::PSTA cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B2b if field :36B::PSTA is... Then one occurrence of :36B::PSTA must be... And the other occurrence of :36B::PSTA must be... Repeated :36B::PSTA//FAMT :36B::PSTA//AMOR Not repeated Not applicable Not applicable MTs 540, 541, 542, and 543 In sequence C, field :36B::SETT cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence C if field :36B::SETT is... Then one occurrence of :36B::SETT must be... And the other occurrence of :36B::SETT must be... Repeated :36B::SETT//FAMT :36B::SETT//AMOR Not repeated Not applicable Not applicable MTs 544, 545, 546, and 547 In sequence C, field :36B::ESTT cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence C if field :36B::SETT is... Then one occurrence of :36B::ESTT must be... And the other occurrence of :36B::ESTT must be... Repeated :36B::ESTT//FAMT :36B::ESTT//AMOR Not repeated Not applicable Not applicable MT 548 In sequence. B, field :36B::SETT cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. 22 July

40 FIN Sequence B if field :36B::SETT is... Then one occurrence of :36B::SETT must be... And the other occurrence of :36B::SETT must be... Repeated :36B::SETT//FAMT :36B::SETT//AMOR Not repeated Not applicable Not applicable MT 564 In each occurrence of subsequence B2, field :93B::ELIG cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B2 if field :93B::ELIG is... Repeated Then one occurrence of :93B::ELIG must be... :93B::ELIG//FAMT and DSS must not be present And the other occurrence of :93B::ELIG must be... :93B::ELIG//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 565 In subsequence B2, field :93B::ELIG cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B2 if field :93B::ELIG is... Repeated Then one occurrence of :93B::ELIG must be... :93B::ELIG//FAMT and DSS must not be present And the other occurrence of :93B::ELIG must be... :93B::ELIG//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 566 In sequence B, field :93B::ELIG cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence B if field :93B::ELIG is... Repeated Then one occurrence of :93B::ELIG must be... :93B::ELIG//FAMT and DSS must not be present And the other occurrence of :93B::ELIG must be... :93B::ELIG//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 567 In sequence B, field :36B::STAQ cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence B if field :36B::STAQ... Then one occurrence of :36B::STAQ must be... And the other occurrence of :36B::STAQ must be... Repeated :36B::STAQ//FAMT :36B::STAQ//AMOR Not repeated Not applicable Not applicable 40 Error Codes

View more

About SWIFTNet FIN messages

Integrator handling input FIN messages

Integrator generation of output FIN messages

FIN is the native SWIFT message definition. The SWIFT standards describe more than 200 FIN message types. FIN Message types include user-to-user messages and system-to-user messages. To handle FIN messages you must create SWIFT-type Business-Documents for each of the message types you want to handle.

See SWIFT-XML Business-Documents for more information.

A FIN message comprises a data file and an associated technical file. A single FIN message can contain multiple component SWIFT messages.

For detailed SWIFT-XML message format information, refer to the standards definitions available online at http://www.iso15022.org/.

Exchanging FIN messages

Integrator uses the SWIFTAlliance Access (SAA) application to access SWIFTNet FIN message exchange services. Integrator can communicate with SAA either via:

  • MQSeries through a dedicated SAA component called MQ-SA
  • Automated File Transfer

SSA, in turn, links to SWIFTNet via SAG and SNL as shown in the following graphic.

Integrator handling of input FIN messages

The following graphic shows an example Integrator integration sequence for processing a SWIFT FIN message input from SWIFTNet.

  1. Integrator receives an incoming FIN message via the Integrator JMS Connector.
  2. The Receive Activity forwards the input message to the next Activity.
  3. If the input message contains multiple SWIFT messages, you configure a FIN Splitter Stage to separate the messages into individual messages.
  4. The FIN Classifier Stage directs the FIN messages to the next Activity based on message content criteria.
  5. Messages that require data transformation or validation are directed to a Map-Stage.
  6. Integrator parses the FIN message to the SWIFT Business-Document.
  7. Integrator performs data and or format transformation on the input message via a Map-Broker in the Map-Stage.
  8. Integrator builds an output message using the output Business-Document. The output Business-Document type corresponds to the type of format you want to handle in the subsequent integration processing stages.
  9. Integrator sends the resulting message to the next Activity in the processing sequence. This could be, for example, a Send Activity that directs the message to a target application, or another Sequential Activity for additional message enhancement or transformation.

Integrator generation of output FIN messages

The following graphic shows an example Integrator integration sequence for generating a SWIFT FIN message for output towards SWIFTNet.

  1. Integrator receives an incoming message in a standard format via the appropriate connector.
  2. You can use Sequential and Classification Activities to filter the message or enhance the data content before transformation to a SWIFT FIN format.
  3. Integrator parses the input message to a Business-Document that corresponds to the message input type.
  4. Integrator performs format transformation on the message content via a Map-Broker in the Map-Stage. Integrator writes the output to a SWIFT FIN Business-Document.
  5. Integrator builds an output SWIFT FIN message using the output SWIFT FIN Business-Document. Integrator sends the resulting message to the SEND Activity.
  6. The Send Activity forwards the FIN message to SWIFTNet via MQSeries application. Integrator communicates with MQSeries via a JMS Connector.

USER HANDBOOK TRANSLATION

Russian National Association SWIFT prepared Russian translation of the SWIFT User Handbook of November 2019, which includes following books:

Corporate and legal

Glossary
Corporate rules
SWIFT by-laws
General terms and conditions SWIFT
Personal data protection policy
Price-list for Messaging and Solutions
Pricing and invoicing
BIC Policy

Services Description

MA-CUG. For corporates
SCORE 2.6. For corporates
Cash reporting 5.0. Service description

Exceptions and Investigations (E&I) version 1.2:

Service Description
Bank-bank. Message Reference Guide
Integration Guide
Bulk Payments 2.1
BICPlusIBAN Directory
BIC Enquiry Tool 3.0

SWIFTNet FIN

FIN Error Codes
FIN Service Description
FIN System Messages
Standards MT Usage Guidelines
Standards. General Information

Standards:

Category 1 - Customer Payments and Cheques
Category 2 - Financial Institution Transfers
Category 3 - Treasury Markets – Foreign Exchange, Money Markets and Derivatives. Volume 1 (MT 300 – MT 341)
Category 3 - Treasury Markets – Foreign Exchange, Money Markets and Derivatives. Volume 2 (MT 350 – MT 399)
Category 4 – Collection and Cash Letters
Category 5 – Securities Markets. Volume 1 (MT 500 – 518)
Category 5 – Securities Markets. Volume 2 (MT 519-543)
Category 5 – Securities Markets. Volume 3 (MT 544-567)
Category 5 – Securities Markets. Volume 4 (MT 568-599)
Category 6 – Treasury Markets - Commodities
Category 7 – Documentary Credits and Guarantees
Category 8 – Travelers Cheques
Category 9 – Cash Management and Customer Status
Category n – Common Group Messages

Recommendations:

SWIFT-RUR
SWIFT-RUS
ISO 20022.RU

Forging SWIFT MT Payment Messages for fun and pr... research!

TLDR: With a bit of research and support we were able to demonstrate a proof of concept for introducing a fraudulent payment message to move £0.5M from one account to another, by manually forging a raw SWIFT MT103 message, and leveraging specific system trust relationships to do the hard work for us!

Before we begin: This research is based on work we performed in close-collaboration with one of our clients; however, the systems, architecture, and payment-related details have been generalized / redacted / modified as to not disclose information specific to their environment.

With that said... *clears throat*

The typical Tactics, Techniques and Procedures (TTPs) against SWIFT systems we see in reports and the media are - for the most part - the following:

  1. Compromise the institution's network;
  2. Move laterally towards critical payment systems;
  3. Compromise multiple SWIFT Payment Operator (PO) credentials;
  4. Access the institution's SWIFT Messaging Interface (MI);
  5. Keys in - and then authorize - payment messages using the compromised PO accounts on the MI.

This attack-path requires the compromise of multiple users, multiple systems, an understanding of how to use the target application, bypass of 2FA, attempts to hide access logs, avoid alerting the legitimate operators, attempts to disrupt physical evidence, bespoke malware, etc. – so, quite involved and difficult. Now that’s all good and fine, but having reviewed a few different payment system architectures over the years, I can’t help but wonder:

“Can't an attacker just target the system at a lower level? Why not target the Message Queues directly? Can it be done?”

Well, let's find out! My mission begins!

So, first things first! I needed to fully understand the specific “section” of the target institution's payment landscape I was going to focus on for this research. In this narrative, there will be a system called “Payment System” (SYS). This system is part of the institution's back-office payment landscape, receiving data in a custom format and output's an initial payment instructions in ISO 15022 / RJE / SWIFT MT format.  The reason I sought this scenario was specifically because I wanted to focus on attempting to forge an MT103 payment message - that is:

  • MT – “Message Type” Literal;
  • 1 – Category 1 (Customer Payments and Cheques);
  • 0 – Group 0 (Financial Institution Transfer);
  • 3 – Type 3 (Notification);
  • All together this is classified as the MT103 “Single Customer Credit Transfer”.

Message type aside, what does this payment flow look like at a high level? Well I’ve only gone and made a fancy diagram for this!

SWIFT Architecture 01 Dark2

Overall this is a very typical and generic architecture design. However, let me roughly break down what this does:

  1. The Payment System (SYS) ingests data in a custom - or alternative - message format from it's respective upstream systems. SYS then outputs an initial payment instruction in SWIFT MT format;
  2. SYS sends this initial message downstream to a shared middelware (MID) component, which converts (if necessary) the received message into the modern MT format understood by SWIFT - Essentially a message broker used by a range of upstream payment systems within the institution;
  3. MID forwards the message in it's new format on to the institution's Messaging Interface (let's say its SAA in this instance) for processing;
  4. Once received by SAA, the message content is read by the institution's sanction screening / Anti-money laundering systems (SANCT).
  5. Given no issues are found, the message is sent on to the institution's Communication Interface (SWIFT Alliance Gateway), where it's then signed and routed to the recipient institution over SWIFTNet.

OK, so now I have a general understanding of what I'm up against. But if I wanted to exploit the relationships between these systems to introduce a  fraudulent payment without targeting any payment operators, I was going to need to dig deeper and understand the fundamental technologies in use!

So how are these messages actually "passed" between each system? I need to know exactly what this looks like and how its done!

More often than not, Message Queues (MQ) are heavily used to pass messages between components in a large payment system. However, there are also various “Adapter” that may be used between systems communicating directly with the SAG (Such as SAA or other bespoke/3rd party systems). These are typically the:

  • Remote API Host Adapter (RAHA);
  • MQ Host Adapter (MQHA);
  • Web Services Host Adapter (WSHA).

Having identified that MQ was in use, my initial assumption was that there was most likely a dedicated Queue Manager (QM) server somewhere hosting various queues that systems push and pull messages from? However, due to SWIFT CSP requirements, this would most likely - at a minimum - take the form of two Queue Managers. One which manages the queues within the SWIFT Secure Zone, and another that manages queues for the general corporate network and back office systems.

Let's update that diagram to track / represent this understanding:

SWIFT Architecture 02 Dark4

Now I could research how this "messaging" worked!

There are multiple ways to configure Message Queues architectures, in this case there were various dedicated input and output queues for each system, and the message flow looks something like this:

SWIFT MQ 01 Dark2

Full disclosure, turns out it’s hard to draw an accurate - yet simple - MQ flow diagram (that one was basically my 4th attempt). So it’s... accurate "enough" for what we needed to remember!

Now I had a good understanding of how it all worked, it is time to define my goal: "Place a payment message directly on to a queue, and have it successfully processed by all downstream systems".

This sounds simple, just write a message to a queue, right? But there are a few complications!

  1. Why are there few indications of this attack vector in the wild?
  2. How do I even gain “write” access to the right queue?
  3. What protects the message on the queues?
  4. What protects the messages in transit?
  5. What format are the messages in?
  6. What is the correct syntax for that message format at any particular queue (0 margin for error)?
  7. Where does PKI come in? How / where / when are the messages signed?
  8. Can I somehow get around the message signing?
  9. What values in the messages are dependent / controlled / defined by the system processing them (out of my control)?
  10. What is the maximum amount I can transfer using Straight Through Processing, without alerting the institution / requiring manual validation?

But OK, there's no point dwelling on all of that right now, I'll just clearly define what I want to do!

The goal:

  1. Successfully write a payment instruction for 500,000 GBP;
  2. Inject that message directly onto a specific queue;
  3. Have the message pass environment-specific validation rules;
  4. Have the message pass sanctions and AML checks.
  5. Have the message successfully signed;
  6. Have the message pass SWIFTNet-specific validation rules;

What I was not interested in doing for this research - yet needed to understand nevertheless for a full attack chain was:

  1. How to compromise the institution's network;
  2. How to gain access to the MQ admin's workstation;
  3. How to obtain the pre-requisite credentials.

What I wanted to 100% avoid at all costs:

  1. The attack involving SWIFT payment operators in any way;
  2. The attack involving SWIFT application access in any way;
  3. A need to compromise signing keys / HSMs;
  4. A need to compromise SWIFTNet operator accounts or certificates or any type of PKI;.

Now I had an idea of what to do, I needed to make sure I could write a raw MT103 payment instruction! Typically, even when operators write payment messages using a messaging interface application like Alliance Access, they only really write the message “body” via a nice GUI. As raw data this could look something like:

:20:TRANSACTIONRF103
:23B:CRED
:32A:200102GBP500000,00
:33B:GBP500000,00
:50K:/GB22EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59K:/FR20FBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, PARIS, FR
:70:12345-67890
:71A:SHA

I'll break this down in the following table:

NameFieldValue
Transaction Reference20TRANSACTIONRF103
Bank Operation Code23BCRED (Message is to "credit" some beneficiary)
Value Date / Currency / Amount32A200102 (02/01/2020) GBP 500,000.00
Currency / Original Credit Amount33BGBP 500000,00 (£500,000.00)
Ordering Customer50KGB22EBNK88227712345678 (IBAN)
JOHN DOE (Name)
JOHN'S BUSINESS LTD (Line 1)
21 JOHN STREET, LONDON, GB (Line 2)
Beneficiary59KFR20FBNK88332287654321 (IBAN)
ALICE SMITH (Name)
ALICE'S COMPANY (Line 1)
10 ALICE STREET, PARIS, FR (Line 2)
Remittance Information7012345-67890 (essentially a payment reference)
Details of Charge71ASHA (Shared charge between sender and receiver)

Now as this is a valid message body, if I were targeting a payment operator on SWIFT Alliance Access, I could - for the "most" part - simply paste the message into SAA's raw message creation interface and I'd be pretty much done. With the exception of adding the sender / recipient BIC codes and most likely selecting a business unit. However, these values are not stored in the message body.  

Not stored in the message body you say? Well that complicates things! Where are they stored exactly?

The message “body” is referred to as “block 4” (aka the “Text Block”) within the SWIFT MT standard. As suggested by the name, there is probably also a block 1-3. This is correct; and these blocks are typically generated by the payment processing applications - such as SWIFT Alliance Access - and not necessarily input by the operators. A "complete" MT103 message consists of 6 blocks:

  • Block 1 – Basic Header
  • Block 2 – Application Header
  • Block 3 – User Header
  • Block 4 – Text Block
  • Block 5 – Trailer
  • Block 6 – System block

So it looked like I was going to need to learn how to craft these various “blocks” from scratch.

Block 1 (Basic header)

Reading through some documentation, I crafted the following “Basic header” block:

{1:F01EBNKGB20AXXX0000999999}

A breakdown of what this translates too is as follows:

NameValueContext
Basic Header Flag1Block 1 (Not 2, 3, 4, or 5)
Application TypeFFIN Application
Message Type0101 = FIN (I.e not ACK/NACK)
Sender BICEBNKGB20EBNK (Bank Code) GB (Country Code) 20 (Location Code)
Sender Logical TerminalATypically A, unless they are a significantly large institution and require multiple terminals
Sender BranchXXXAll X if no branch needed
Session Number0000The session number for the message
Sequence Number 999999The sequence number of the message

Taking a step back, I already identified two potential problems: the “session” and “sequence” numbers! These are described as follows:

  • Session Number – Must also equal the current application session number of the application entity that receives the input message.
  • Sequence number – The sequence number must be equal to the next expected number.

Hmmm, at this point I was not sure how I could predetermine a valid session and/or sequence number - considering they seemed to be application and "traffic" specific? But there was nothing I could do at the time, so I noted it down in a list of "issues/blockers" to come back to later.

Block 2 (Application Header)

A bit more dry reading later, I managed to also throw together an application header:

{2:I103FBNKFR20XXXXN}

Again, I’ve broken this down so it makes sense (if it didn’t already; I’m not one to assume):

NameValueContext
Application Header Flag2Block 2
I/O IdentifierIInput Message (a message being sent)
Message Type103103 = Single Customer Credit Transaction
Recipient BICFBNKFR20FBNK (Bank Code) FR (Country Code) 20 (Location Code)
Recipient Logical TerminalXAll General Purpose Application Messages must use "X"
Recipient BranchXXXAll General Purpose Application Messages must use "XXX"
Message PriorityNNormal (Not Urgent)

Awesome! No issues crafting this header!

Note: At this point I should probably mention that these BIC codes are not "real", however are accurate in terms of in format and length.

Block 3 (User Header)

The third block is called the “User Header” block, which can be used to define some “special” processing rules. By leverage this header, I could specify that the message should be processed using “Straight Through Processing” (STP) rules which essentially attempts to ensure that the message is processed end-to-end without human intervention. This could be specified as follows:

{3:{119:STP}}

However, this was not yet a valid header! As of November 2018 the user header requires a mandatory “Unique end-to-end transaction reference” (UETR) value, which was introduced as part of SWIFT's Global Payments Innovation initiative (gpi)!

This is a Globally Unique Identifier (GUID) compliant with the 4th version of the generation algorithm used by the IETF standard "RFC4122". This consists of 32 hexadecimal characters, divided into 5 parts by hyphens as follows:

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

where:

  • x – any lowercase hexadecimal character;
  • 4 – fixed value;
  • y – either: 8, 9, a, b.

This value can be generated using Python as seen below:

$ python -c 'import uuid; id = uuid.uuid4(); print "Value:", id; print "Version:", id.version, id.variant'
Value: 8b1b42b5-669f-46ff-b2f2-c21f99788834
Version: 4 specified in RFC 4122

With an acceptable UETR generated, this is how the third block looked:

{3:{119:STP}{121:8b1b42b5-669f-46ff-b2f2-c21f99788834}}

And as before, a breakdown can be found below:

NameValueContext
User Header Flag3Block 3
Validation Flag119Indicates whether FIN must perform any type of special validation
Validation FieldSTPRequests the FIN system to validate the message according to the straight through processing principles
UETR Field121Indicates the Unique end-to-end transaction reference value
UETR Value8b1b42b5-669f-46ff-b2f2-c21f99788834Unique end-to-end transaction reference used to track payment instruction

Block 5 and 6 (Trailer and System Blocks)

I’ve already discussed “block 4” (the message body), so to wrap this section up, I'll be looking at the final 2 blocks: Block 5, aka the “Trailer”; and block S, aka the “System” block.

Before going forward, let me take a moment to explain the pointlessly complicated concept of input and output messages:

  • An “input” message (I) is a message which is traveling “outbound” from the institution. So this is a message being “input” by an operator and sent by the institution to another institution.
  • An “output” message (O) is a message which is traveling “inbound” to the institution. So this is a message being “output” by SWIFTNet and being received by the institution.

OK, moving swiftly (aaaahhhhh!) on.

For Input messages, these blocks were not too much of a problem. The headers only really seemed to be used to flag whether the message was for training / testing or to flag if it was a possible duplicate, which syntactically took the following form:

{5:{TNG:}}{S:{SPD:}}

Where “TNG” indicated “training” and “SPD” indicated “possible duplicate”.

However, with Output messages, it got considerably more complicated. An example of what the trailer and system block could look like on an Output message is the following:

{5:{MAC:13461AEF}{CHK:4A3367FD3D76}{TNG:}}{S:{SPD:}{SAC:}{COP:P}
{MDG:5E87F8F390E5FB886E8311E4D7C994371FA9AF3119B2C314DAE458738AFF08AC}}

A breakdown of these various values is:

Trailer ({5:)
MAC – Message Authentication Code calculated based on the entire contents of the message using a key that has been exchanged with the destination bank and a secret algorithm;
CHK – This is a PKI checksum of the message body, used to ensure the message has not been corrupted in transit;
TNG – A flag to indicate that the message is a Testing and Training Message.

System ({S:)
SPD – Possible Duplicate Flag
SAC – Successfully Authenticated and Authorized Flag. This is only present if:

  1. Signature verification was successful.
  2. RMA (Relationship Management Application) authorization and verification was successful.

COP – Flag indicating that this is the primary message copy;
MDG – The HMAC256 of the message using LAU keys.

However, these seemed to only be values I would need to consider if I was to try and forge an “incoming” message from SWIFTNet or an "outbound" message on the output of the SAG.

So... I'll stick with crafting an “input" message trailer:

{5:{TNG:}}{S:{SPD:}}

Now, having said all that, it turned out the trailer block did seem to sometimes hold a MAC code and a message checksum (sigh), meaning I actually needed to construct something like:

{5:{MAC:XXXXXXXX}{CHK:XXXXXXXXXXXX}{TNG:}}{S:{SPD:}}

So that was +2 to my "issues/blockers" list. However, issues aside, I now understood the complete message format, and could put it all together and save the following as a draft / template MT103 message:

{1:F01EBNKGB20AXXX8888999999}
{2:I103FBNKFR20XXXXN}
{3:{119:STP}{121:8b1b42b5-669f-46ff-b2f2-c21f99788834}}
{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200102GBP500000,00
:33B:GBP500000,00
:50K:/GB22EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/FR20FBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, PARIS, FR
:70:12345-67890
:71A:SHA
-}
{5:{MAC:XXXXXXXX}{CHK:YYYYYYYYYYYY}{TNG:}}{S:{SPD:}}

Highlighted in bold above are the areas of the message I was - at this point - unable to pre-determine. Nevertheless, a summary of what that the message describes is:

  • Using the transaction reference “TRANSACTIONRF103”;
  • please transfer 500,000.00 GBP;
  • from John Doe, (IBAN: GB22EBNK88227712345678) at “English Bank” (BIC: EBNKGB20);
  • to Alice Smith (IBAN: FR20FBNK88332287654321) at “French Bank” (BIC: FBNKFR20);
  • Furthermore, please ensure the transaction charge is shared between the two institutions;
  • and mark the payment with a reference of “12345-67890”.

To wrap up this section, i wanted to take a moment to explain some logic behind the target of 500,000 GBP, as it is also important.

Aside from the many reasons it would be better to transfer [even] smaller amounts (which is an increasingly common tactic deployed by modern threat actors), why not go higher? This is where it’s important to understand the system and environment you are targeting.

In this instance, let's assume that by doing recon for a while I gathered the understanding that:

  • If a message comes from SYS which is over £500k;
  • even if it has been subject to a 4 eye check;
  • and even if it is flagged for STP processing;
  • route it to a verification queue and hold it for manual verification.

This was because a transaction over £500k was determined to be “abnormal” for SYS. As such, if my transaction was greater, the message would not propagate through all systems automatically.

OK, so now that I understood:

  • how the system worked;
  • how it communicated;
  • the fundamental structure of a raw MT103 payment messages;
  • and how much I could reliably [attempt] to transfer.

And with that, it was time to take a break from MT standards and establish an understanding of how I would even get into a position to put this into practice!

To place a message on a queue, I was going to need two things:

  • Access to the correct queue manager;
  • Write access to the correct queues.

Depending on the environment and organisation, access to queue managers could be quite different and complex. However a bare-bones setup may take the following form:

  • An MQ Administrator accesses their dedicated workstation using AD credentials;
  • They then remotely access a dedicated jump server via RDP which only their host is whitelisted to access;
  • This may be required as the queues may make use of Channel Authentication Records, authorizing specific systems and user accounts access to specific queues;
  • The channels may further be protected by MQ Message Encryption (MQME) which encrypts messages at rest based on specific channels. As such, even if someone was a “super duper master admin” they would only be able to read / write to queues specifically allocated to them within the MQME configuration file (potential target for another time?);
  • The MQ Admin can then use tools such via the Jump Server to read/write to their desired message queues.

So, in this scenario, to gain access to the message queues I - as an attacker - would need to compromise the MQ admin’s AD account and workstations, then use this to gain access to the jump host, from where I could then access the message queues given I knew the correct channel name and was configured with authorization to access it... and maybe throw some MFA in there...

That is understandably a significant requirement! However, when discussion sophisticated attacks against Financial Market Infrastructure (FMI), it is more than reasonable to accept that an Advanced Persistent Threat (APT) would see this as a feasible objective - We don't need to dig into the history of how sophisticated attacks targeting SWIFT systems can be.

Next, it was time to finally identify a feasible attack vector for message forgery.

Now with an idea of how to gain the right access, as well as an understanding of the various technologies and security controls in place; I update my diagram:

SWIFT Security Dark2

You may have noticed I've added something called “LAU” around the SAA-to-SAG adapter, and another “LAU” to the MID-to-SAA MQ channels, which I have yet to explain.  “Local Authentication” (LAU) is a security control implemented by SWIFT to authenticate messages using a pair of shared keys between two systems. These keys are combined and used to generate a SHA256 HMAC of the message and append it to the S block. This can then be validated by the recipient system. Effectively, this validates the origin and authenticity of a message. As such, even if an attacker was in position to introduce a fraudulent payment, they'd first need to compromise both the left and the right LAU signing keys, generate the correct HMAC, and append it to the message in order to have it accepted / processed successfully.

But LAU aside, I now just needed to figure out which queue to target! There were a lot of queues to work with as each system essentially has multiple “input” and “output” queues. With that in mind, it was important to note that: an incoming message would require being in the format expected by the target system (from a specific upstream system) and an outgoing message would need to be in the format “produced” by one target system and “expected / ingested / processed” by its respective downstream system. So to figure this out, I worked backwards from the Gateway.

Targeting SAG

This was the least feasible attack vector!

  1. I hadn't really looked into how the SWIFT adapters worked - If only I could research literally everything);
  2. SAA and SAG implemented LAU on messages sent between them - An excellent security control!;
  3. The output of SAG was directly on to SWIFTNet which would entail all sorts of other complications - this is an understatement)!

Next!

Targeting SAA

So what if I wanted to drop a message on the “outbound” channel of SAA?

LAU and the SWIFT adapter aside, remember those session and sequence numbers? Well, messages which leave SAA are in the near-final stages of their outbound life-cycle, and as far as I understood would need to have valid session and sequence values. Given I didn't know how to generate these values without gaining access to SAA or how they worked in general (and lets not forget the LAU signing) this didn't currently seem feasible.

Next!

Targeting SANCT

This solution didn't actually transport messages back and forth; it just reads messages off the queues and performed checks on their details. Not much I could wanted to leverage here.

Targeting MID

To target MID, I could try and inject a message onto SAA’s “input” queue, or the “output” queue of MID. This would only need to match the format of messages produced by the Middleware solution (MID). Following this, in theory, the [mistial] message session and sequence number would be added by SAA, along with the UETR. This was promising!

However, MID was a SWIFT “message partner”, which are typically solutions developed using the Alliance Access Development Kit that allows vendors to develop SWIFTNet compatible software, and consequentially, implement LAU. So again, in-order to forge a message here, I’d need to compromise the left and right LAU signing keys used between SAA and MID, manually HMAC the message (correctly!), and then place it on the correct queue... This also no longer looked promising...

Targeting SYS

OK, how about the input of the next system down - the "Payment System"?

As described previously, the inbound data was a custom “application specific” payment instruction from the institutions back office systems, and not a SWIFT MT message. This would be an entirely new core concept I'd need to reverse - not ideal for this project.

But how about the output queue?

Although SYS received custom format data, I found that it output what seemed to be an initial SWIFT MT messages. This was perfect! Additionally, SYS did not have LAU between itself and MID because (unlike MID) SYS was not a SWIFT message partner, and was just one of many-many systems within the institution that formed their overall payment landscape.

Additionally, because SYS was esentially just one small piece of a much larger back office architecture, it was not part of the SWIFT Secure Zone (after all you cant have your entire estate in the Secure Zone - that defeats the purpose) and as such, made use of the Queue Manager within a more accessible section of the general corporate environment (QM1).

With this in mind, and having - in theory - compromised the MQ admin, I could leverage their access to access on the corporate network to authenticate to QM1. I could - in theory -  then write a fraudulent payment message to the SYS “output” queue, which we will call “SYS_PAY_OUT_Q” from here on.

OK! It seems like I finally had an idea of what to do! But before I could put it into practice, I of course needed to create a diagram of the attack:

SWIFT Attack Dark2

I think it’s important to take a minute to refer back to the concept of “trust” which is what lead to this attack diagram. My theory behind why this may work is because the MID application, implicitly trusts whatever it receives from its respective upstream systems. This is intentional, as by design the security model of the payment landscape ensures that: at any point a message can be created, a 4 (or 6) eye check is performed. If there was a system whose purpose it was to ensure the validity of a payment message at any point upstream, the downstream systems should have no real issue processing that message (with some exceptions). After all, It would be next to-impossible to maintain a high-throughput payment system without this design.

And with that said, the plan was now clear:

  • Leverage the access of a Message Queue administrator;
  • to abuse the “trust relationship” between SYS, MID, and SAA;
  • to introduce a fraudulent payment message directly on to the output queue of SYS;
  • by leaning on my new found understanding of complete MT103 payment messages.

It was finally time to try to demonstrate a Proof-of-Concept attack!

So at this point I believe I had everything I needed in order to execute the attack:

  • The target system!
  • The message format!
  • The queue manager!
  • The queue!
  • The access requirements!
  • The generously granted access to a fully functional SWIFT messaging architecture! (that’s a good one to have!)
  • The extra-generously granted support of various SMEs from the target institution! (This was even better to have!)

Message Forgery

I needed to begin by creating a valid payment message using valid details from the target institution. So before moving on I was provided with the following (Note: as with many things in this post, these details have been faked):

  • Debtor Account Details – John Doe, GB12EBNK88227712345678 at EBNKGB20
  • Creditor Account Details – Alice Smith, GB15EBNK88332287654321 at EBNKGB20

Some of you may have notice that the sending and receiving BIC’s are the same. This was because, for the sake of the research, I wanted to send the message back to the target institution via SWIFTNet so that I could analyse its full end-to-end message history. Furthermore, you may have noticed we are using "test & training" BIC code (where the 8th character is a 0) - this was to make sure, you know, that I kept my job.

But yes, with access to these "valid" account details and the knowledge gained during the research so far, I could now forge a complete Input MT103 messages:

{1:F01EBNKGB20AXXX0000000000}
{2:I103EBNKGB20XXXXN}
{3:{119:STP}{121:eb02c40e-e060-400a-ac74-47f076dd26e3}}
{4:
:20:TRANSACTIONREF103
:23B:CRED
:32A:200103GBP500000
:33B:GBP500000
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}{5:{TNG:}}{S:{SPD:}}

Note: Field 33B is actually an optional field, however, the MT standard stated that “If the country codes of both the Sender’s and the Receiver’s BIC belong to the country code list, then field 33B is mandatory”. As such, if 33B was not present in the message, it would fail network validation rules and SWIFTNet would return a NAK with the error code: D49.

Optional / Mandatory fields aside, it was not quite that simple! There were a few minor changes I needed to make based on the specific point in the message's its life-cycle I was planning to introduce it!

As I list these changes, remember that the objective is to introduce the message to the output queue of SYS (Which exists before MID, SAA and SAG)

  1. The first 3 blocks needed to be placed on a single line;
  2. Remove field 121 (UETR) from the User Header, as this would be generated by SAA during processing;
  3. Remove 1 character from the transaction reference as it needed to be exactly 16 characters (classic user error);
  4. Add decimal point to transaction amount using a comma - otherwise it would fail syntax validation rules;
  5. Ensure the IBAN's were real and accurate, otherwise it seemed the message would fail some type of signature validation on the SWIFT network. The IBANs are fake here, but during the real PoC we used accurate account details in collaboration with the target institution;
  6. Remove the trailer block (5) - as this would be appended by SAA during processing;
  7. Remove the System Block (S) - as this would be completed by the SAG.

And the final message was as follows:

{1:F01EBNKGB20AXXX8888999999}{2:I103EBNKGB20XXXXN}{3:{119:STP}}{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200103GBP500000,00
:33B:GBP500000,00
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}

Note that the location in which I introduce the message has resolved all of the "issues / blockers" I'd tracked whilst researching the message structure! It would seem the further upstream you go, the easier the attack becomes - given MQ is still used as a transport medium.

Message Injection

Now I had my raw MT103 message, I just need to save it to a file (“Message.txt” - sure why not) and place onto the “SYS_PAY_OUT_Q” queue using one of the admin's tools:

  1. With access to a sole MQ Administrator's AD account;
  2. We connect to the MQ admins machine;
  3. Log into the Jump Server;
  4. Open our MQ tools of choice and authenticate to queue manager (QM1) where the output queue for SYS was managed;
  5. Connected to the "SYS_PAY_OUT_Q" queue;
  6. Selected my forged “Message.txt” file;
  7. Invoked the “write to queue” function;

And it was off!

Loggin in to Alliance Access and opening the message history tab, we sat awaiting for an update. Waiting, waiting, waiting… waiting… and...

ACK! It worked!

That's a joke; did we hell receive an ACK!

See, this last section is written slightly more "linear" than what actually happened. Remember those "tweaks" used to fix the message in the previous section? I hadn't quite figured that out yet...

So roughly seven NACKs later - each time troubleshooting and then fixing a different issues - we did indeed, see an ACK! The message was successfully processed by all systems, passed target system validation rules, passed sanctions and AML screening, passed SWIFTNet validation rules, and SWIFT’s regional processor had received the message and sent an "Acknowledgement of receipt" response to the sending institution!

For the sake of completeness, I’ve included the ACK below:

{1:F21EBNKGB20AXXX1947392344}{4:{177:2001031102}{451:0}}

And of course a breakdown of what it all means:

NameValueContext
Basic Header Flag1Block 1
Application TypeFF = FIN Application
Message Type2121 = ACK
Institution CodeEBNKGB20AXXXEBNKGB20 (BIC) A (Logical Terminal) XXX (Branch)
Sequence and Session No.19473923441947 (Sequence No.) 392344 (Session No.)
Date Tag177200103 (Date) 1102 (Time)
Accept / Reject Tag4510 = Accepted by SWIFTNet

Excellent! WooHoo! It worked! ... That took a lot of time and effort!

Closer Inspection

But the ACK wasn't enough, I wanted to make sure I understood what had happened to the message throughout its life-cycle. From the message I placed on the initial queue, to being processed by SWIFTNet.

Thankfully, as we sent the message back to the target institution we could see its entire message history. I already knew what the raw message placed on the queue looked like, so I wanted to focus on what became of the message once it had been processed by SAA:

{1:F01EBNKGB20AXXX8888999999}{2:I103EBNKGB20XXXXN}{3:{119:STP}{121:b42857ce-3931-49bf-ba34-16dd7a0c929f}}{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200103GBP500000,00
:33B:GBP500000,00
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}
{5:{TNG:}}{S:{SPD:}}
  • The end-to-end tracking UUID had been generated and added (b42857ce-3931-49bf-ba34-16dd7a0c929f) in block 3;
  • The message trailer had been added ({5:{TNG:}}) where I could see that - due to the BIC code used - SAA had flagged the message as "test and training".
  • Additionally, an initial System Block segment had been added ({S:{SPD:}}), tagging the message as a possible duplicate. I wonder why - *cough* 7th attempt *cough*?

OK, so that was SAA. Now let’s see how it looked it once it passed through the Gateway and regional processor:

{1:F01EBNKGB20AXXX1947392344}{2:O1031102200103EBNKGB20AXXX19473923442001031104N}{3:{119:STP}{121:b42857ce-3931-49bf-ba34-16dd7a0c929f}}{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200103GBP500000
:33B:GBP500000
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}
{5:{MAC:13579112}{CHK:D8E8FCA2DC0F}{TNG:}}{S:{SPD:}{SAC:}{COP:P}}

OK, we can see a few changes now.

  • The session and sequence numbers have been populated (1947392344);
  • The I/O identifier in block 2 has been updated to track that it is now an "Output" message;
  • The additional data within Block 2 is a combination of the input time, date, BIC, session and sequence numbers, output date/time, and priority;
  • The trailer has been updated with a message authentication code (MAC) calculated based on the entire contents of the message using a pre-shared key and a secret algorithm;
  • Additionally, a checksum of the message body has been stored within the trailer’s “CHK” tag. This is used by the network to ensure message integrity.

I also took a look at the entire outbound message history, just to see all the “Success” and “No violation” statements to make it feel even more awesome!

So that's that really...

With a bit of research and support I was able to demonstrate a PoC for introducing a fraudulent payment message to move funds from one account to another, by manually forging a raw SWIFT MT103 single customer credit transfer message, and leveraging various system trust relationships to do a lot of the hard work for me!

As mentioned briefly in the introduction, this is not something I have really seen or heard of happening in practice or in the "wild". Perhaps because it clearly takes a lot of work... and there is a huge margin for error. However, if an adversary has spent enough time inside your network and has had access to the right documentation and resources, this may be a viable attack vector. It definitely has its benefits:

  • No need to compromise multiple payment operators;
  • No requirement to compromise - or establish a foothold within - the SWIFT Secure Zone;
  • No requirement to bypass MFA and gain credentials for a messaging interface;
  • No generation of application user activity logs;
  • No payment application login alerts;
  • No bespoke app-specific and tailored malware;
  • And all the other things associated with the complex task of gaining and leveraging payment operator access.

All an attacker may need to do is compromise one specific user on the corporate network: a Message Queue administrator.

The industry is spending a lot of time and effort focused on securing their payment systems, applications, processes, and users to keep - among other things - payment operators safe, Messaging Interfaces locked down, and SWIFT systems isolated. But the reality is,; the most valuable and most powerful individual in the entire model, might just be a single administrator!

As always, a security model is only as strong as its weakest link. If you're not applying the same level of security to your wider institution, there may very well be many weak links within the wider network which chain together and lead to the comrpomise of systems which feed into your various payment environment.

I think the main thing to remember when reflecting on this research is that it did not abuse any vulnerabilities within the target institution's systems, or even vulnerabilities or weaknesses within the design of their architecture. It simply leverages the legitimate user access of the Message Queue administrators and the trust relationships that exist by design within these types of large-scale payment processing systems.

So the harsh reality is, there is no particular list of recommendations for preventing this type of attack in itself. However, the main point to drive home is that you must ensure the security of your users - and overall organisation - is of a high enough standard to protect your highest privileged users from being compromised. Things such as:

  • Strong monitoring and alerting controls for anomalous behaviour;
  • Requirements for Multi-Factor authentication for access to critical infrastructure;
  • Segregation of critical infrastructure from the wider general IT network;
  • Strong password policies;
  • Well rehearsed incident detection and incident response policies and procedures;
  • Frequent high-quality security awareness training of staff;
  • Secure Software Development training for your developers;
  • Routine technical security assessments of all critical systems and components;
  • The use of 3rd party software from reputable and trusted vendors;

However, in the context of Message Queues, there is one particular control which I think is extremely valuable: The implementation of channel specific message signing! This, as demonstrated by SWIFT's LAU control, is a good way in which to ensure the authenticity of a message.

As discussed, LAU is - as far as I know at the time of writing - a SWIFT product / message partner specific control. However it's concept is universal and could be implemented in many forms, two of which are:

  • Update your in-house application's to support message signing, natively;
  • Develop a middleware component which performs message signing on each system, locally.

This is a complex requirement as it requires considerable effort on the client’s behalf to implement either approach. However, SWIFT provides guidance within their Alliance Access Developers guide on how to implement LAU in Java, Objective C, Scala and Swift;

  1. Strip any S block from the FIN message input. Keep only blocks 1: through 5;
  2. Use the FIN message input as a binary value (unsigned char in C language, byte in Java). The FIN message input must be coded in the ASCII character set;
  3. Combine the left LAU key and the right LAU key as one string. The merged LAU key must be used as a binary value (unsigned char in C language, byte in Java). The merged LAU key must be coded in the ASCII character set;
  4. Call a HMAC256 routine to compute the hash value. The hash value must also be treated as a binary value (unsigned char in C language, byte in Java). The HMAC size is 32 bytes;
  5. Convert the HMAC binary values to uppercase hexadecimal printable characters.

An example of how this may work in the more flexible middleware solution proposed is where the original service is no longer exposed to the network, and is altered to only communicate directly with the custom "LAU-eqsue" service on its local host. This service would then sign and route the message to its respective queue.

When received, the core of the recipient payment service would seek to retrieve its messages from the queues via the "LAU-esque" signing middleware, which would retrieve the message and subsequently verify its origin and authenticity by re-calculating the signature using their shared (secret) keys. Key-pairs could further be unique per message flow. This design could allow for the signing to be used as a way to validate the origin of a message even if it had passed through multiple [local] intermediary systems.

As a final bit of creative effort, I made yet another diagram to represent what this could perhaps look like - if life was as easy as a diagram:

SWIFT Help Dark

If you made it this far thanks for reading all... ~6k words!? I hope you found some of them interesting and maybe learned a thing or two!

I'd like express our gratitude to the institution who facilitated this research, as well as specifically to the various SMEs within that institution who gave their valuable time to support it throughout.

Fineksus - SWIFT Standard Changes 2019

https://fineksus.com/swift-mt-standard-changes-2019/

Paiementor - SWIFT MT Message Structure Blocks 1 to 5

https://www.paiementor.com/swift-mt-message-structure-blocks-1-to-5/

SEPA for corporates - The Difference between a SWIFT ACK and SWIFT NACK

https://www.sepaforcorporates.com/swift-for-corporates/quick-guide-swift-mt101-format/

SEPA for corporates - Explained: SWIFT gpi UETR – Unique End-to-End Transaction Reference

https://www.sepaforcorporates.com/swift-for-corporates/explained-swift-gpi-uetr-unique-end-to-end-transaction-reference/

M DIBA - LAU for SWIFT Message Partners

https://www.linkedin.com/pulse/lau-swift-message-partners-mohammad-diba-1/

Prowide - About SWIFT

https://www.prowidesoftware.com/about-SWIFT.jsp

Microsoft - SWIFT Schemas

https://docs.microsoft.com/en-us/biztalk/adapters-and-accelerators/accelerator-swift/swift-schemas

SWIFT FIN Guru - SWIFT message block structure

http://www.swiftfinguru.com/2017/02/swift-message-block-structure.html

 

SWIFT Error Codes

  • Article
  • 2 minutes to read

SWIFT defines many network-imposed validations against the set of financial (FIN) messages. Each validation relates to a type of check against the contents of the message, and is associated with a three-character error code. The first character of the error code implies the class of the problem detected, and is a letter. The remaining two characters denote the detail of the error (when combined with the class) and always appear as a two-digit code.

Class of errors

The following table lists the letter designations, validation type, rule change associated with each class of error, and whether or not the class of error is supported.

ClassValidation type and rule changeSupported?
C, D, ESemantic validation rules 0-299Supported
KnnInvalid code word in field nnSupported
M50Message length exceededUnsupported
M60Non-SWIFT character encounteredSupported
TText validation error codesSupported
GSpecific error codes for message user group (MUG) Textval rulesUnsupported
BSpecial error codes for value-added servicesUnsupported

All SWIFT errors should be referenced in the SWIFT User Handbook. For more information and for a complete list of SWIFT error codes, refer to the Message Format Validation Rules volume of the SWIFT User Handbook. A4SWIFT implements the rules in the September 2003 edition of this publication. You can access the SWIFT Web site at https://go.microsoft.com/fwlink/?LinkId=27885.

Validation errors

There are some codes which are defined by A4SWIFT. These error codes are used in the validation/network rules created and implemented by A4SWIFT, so there is no corresponding error code defined by SWIFT for such rules. Below table shows the error code and corresponding case in which the error is thrown. is the particular field which throws the error.

Error CodeDescription
A4SWIFT001The first character of multiline field cannot be ':' or '-' character for second and subsequent lines.
A4SWIFT002Field contains invalid value.

Note

BizTalk Accelerator for SWIFT (A4SWIFT) includes support for some legacy messages, because internal applications might use these messages. Therefore, A4SWIFT maintains the associated SWIFT rules and error codes.

More good info

Troubleshooting: Issues and ResolutionsKnown IssuesCommon terms and definitions

About SWIFTNet FIN messages

Integrator handling input FIN messages

Integrator generation of output FIN messages

FIN is the native SWIFT message definition. The SWIFT standards describe more than 200 FIN message types. FIN Message types include user-to-user messages and system-to-user messages. To handle FIN messages you must create SWIFT-type Business-Documents for each of the message types you want to handle.

See SWIFT-XML Business-Documents for more information.

A FIN message comprises a data file and an associated technical file. A single FIN message can contain multiple component SWIFT messages.

For detailed SWIFT-XML message format information, refer to the standards definitions available online at http://www.iso15022.org/.

Exchanging FIN messages

Integrator uses the SWIFTAlliance Access (SAA) application to access SWIFTNet FIN message exchange services. Integrator can communicate with SAA either via:

  • MQSeries through a dedicated SAA component called MQ-SA
  • Automated File Transfer

SSA, in turn, links to SWIFTNet via SAG and SNL as shown in the following graphic.

Integrator handling of input FIN messages

The following graphic shows an example Integrator integration sequence for processing a SWIFT FIN message input from SWIFTNet.

  1. Integrator receives an incoming FIN message via the Integrator JMS Connector.
  2. The Receive Activity forwards the input message to the next Activity.
  3. If the input message contains multiple SWIFT messages, you configure a FIN Splitter Stage to separate the messages into individual messages.
  4. The FIN Classifier Stage directs the FIN messages to the next Activity based on message content criteria.
  5. Messages that require data transformation or validation are directed to a Map-Stage.
  6. Integrator parses the FIN message to the SWIFT Business-Document.
  7. Integrator performs data and or format transformation on the input message via a Map-Broker in the Map-Stage.
  8. Integrator builds an output message using the output Business-Document. The output Business-Document type corresponds to the type of format you want to handle in the subsequent integration processing stages.
  9. Integrator sends the resulting message to the next Activity in the processing sequence. This could be, for example, a Send Activity that directs the message to a target application, or another Sequential Activity for additional message enhancement or transformation.

Integrator generation of output FIN messages

The following graphic shows an example Integrator integration sequence for generating a SWIFT FIN message for output towards SWIFTNet.

  1. Integrator receives an incoming message in a standard format via the appropriate connector.
  2. You can use Sequential and Classification Activities to filter the message or enhance the data content before transformation to a SWIFT FIN format.
  3. Integrator parses the input message to a Business-Document that corresponds to the message input type.
  4. Integrator performs format transformation on the message content via a Map-Broker in the Map-Stage. Integrator writes the output to a SWIFT FIN Business-Document.
  5. Integrator builds an output SWIFT FIN message using the output SWIFT FIN Business-Document. Integrator sends the resulting message to the SEND Activity.
  6. The Send Activity forwards the FIN message to SWIFTNet via MQSeries application. Integrator communicates with MQSeries via a JMS Connector.

SWIFT Error Codes

  • Article
  • 2 minutes to read

SWIFT defines many network-imposed validations against the set of financial (FIN) messages. Each validation relates to a type of check against the contents of the message, and is associated with a three-character error code. The first character of the error code implies the class of the problem demigrator .exe error, and is a letter. The remaining two characters denote the detail of the error (when combined with the class) and always appear as a two-digit code.

Class of errors

The following table lists the letter designations, validation type, rule change associated with each class of error, and whether or not the class of error is supported.

ClassValidation type and rule changeSupported?
C, D, ESemantic validation rules 0-299Supported
KnnInvalid code word in field nnSupported
M50Message length exceededUnsupported
M60Non-SWIFT character encounteredSupported
TText validation error codesSupported
GSpecific error codes for message user group (MUG) Textval rulesUnsupported
BSpecial error codes for value-added servicesUnsupported

All SWIFT errors should be referenced in the SWIFT User Handbook. For more information and for a complete list of SWIFT error codes, refer to the Message Format Validation Rules volume of the SWIFT User Handbook. A4SWIFT implements the rules in the September 2003 edition of this publication. You can access the SWIFT Web site at https://go.microsoft.com/fwlink/?LinkId=27885.

Validation errors

There are some codes which are defined by A4SWIFT. These error codes are used in the validation/network rules created and implemented by A4SWIFT, so there is no corresponding error code defined by SWIFT for such rules. Below table shows the error code and corresponding case in which the error is thrown. is the particular field which throws the error.

Error CodeDescription
A4SWIFT001The first character of multiline field cannot be ':' or '-' character for second and subsequent lines.
A4SWIFT002Field contains invalid value.

Note

BizTalk Accelerator for SWIFT (A4SWIFT) includes support for some legacy messages, because internal applications might use these messages. Therefore, A4SWIFT maintains the associated SWIFT rules and error codes.

More good info

Troubleshooting: Issues and ResolutionsKnown IssuesCommon terms and definitions

Forging SWIFT MT Payment Messages for fun and pr. research!

TLDR: With a bit of research and support we were able to demonstrate a proof of concept for introducing a fraudulent payment message to move £0.5M from one account to another, by manually forging a raw SWIFT MT103 message, and leveraging specific system swiftnet fin error codes relationships to do the hard work for us!

Before we begin: This research is based on work we performed in close-collaboration with one of our clients; however, the systems, architecture, and payment-related details have been generalized / redacted / modified as to not disclose information specific to their environment.

With that said. *clears throat*

The typical Tactics, Techniques and Procedures (TTPs) against SWIFT systems we see in reports and the media are - for the most part - the following:

  1. Compromise the institution's network;
  2. Move laterally towards critical payment systems;
  3. Compromise multiple Swiftnet fin error codes Payment Operator (PO) credentials;
  4. Access the institution's SWIFT Messaging Interface (MI);
  5. Keys in - and then authorize - payment messages using the compromised PO accounts on the MI.

This attack-path requires the compromise of multiple users, multiple systems, an understanding of how to use the target application, bypass of 2FA, attempts to hide access logs, avoid zabbix configure error jabber library not found the legitimate operators, swiftnet fin error codes, attempts to disrupt physical evidence, bespoke malware, etc. – so, swiftnet fin error codes, quite involved and difficult, swiftnet fin error codes. Now that’s all good and fine, but having reviewed a few different payment system architectures over the years, I can’t help but wonder:

“Can't an attacker just target the system at a lower level? Why not target the Message Swiftnet fin error codes directly? Can it be done?”

Well, let's find out! My mission begins!

So, first things first! I needed to fully understand the specific “section” of the target institution's payment landscape I was going to focus on for this research. In this narrative, there will be a system called “Payment System” (SYS). This end too end error is part of the institution's back-office payment landscape, receiving data in a custom format and output's an initial payment instructions in ISO 15022 / RJE / SWIFT MT format.  The reason I sought this scenario was specifically because I wanted to focus on attempting to forge an MT103 payment message - that is:

  • MT – “Message Type” Literal;
  • 1 – Category 1 (Customer Payments and Cheques);
  • 0 – Group 0 (Financial Institution Transfer);
  • 3 – Type 3 (Notification);
  • All together this is classified as the MT103 “Single Customer Credit Transfer”.

Message type aside, what does this swiftnet fin error codes flow look like at a high level? Well I’ve only gone and made a fancy diagram for this!

SWIFT Architecture 01 Dark2

Overall this is a very typical and generic architecture design, swiftnet fin error codes. However, let me roughly break down what this does:

  1. The Payment System (SYS) ingests data in a custom - or alternative - message format from it's respective upstream systems. SYS then outputs an initial payment instruction in SWIFT MT format;
  2. SYS sends this initial message downstream to a shared middelware (MID) component, which converts (if necessary) the received message into the modern Critical error 1337 e183 motorola k1 format understood by SWIFT - Essentially a message broker used by a range of upstream payment systems within the institution;
  3. MID forwards the message in it's new format on to the institution's Messaging Interface (let's say its SAA in this instance) for processing;
  4. Once received by SAA, the message content is read by the institution's sanction screening / Anti-money laundering systems (SANCT).
  5. Given no issues are found, the message is sent on to the institution's Communication Interface (SWIFT Alliance Gateway), where it's then signed and routed to the recipient institution over SWIFTNet.

OK, so now I have swiftnet fin error codes general understanding of what I'm up against, swiftnet fin error codes. But if I wanted to exploit the relationships between these systems to introduce a  fraudulent payment without targeting any payment operators, I was going to need to dig deeper and understand the fundamental technologies in use!

So how are these messages actually "passed" between each system? I need to know exactly what this looks like and how its done!

More often than not, Message Queues (MQ) are heavily used to pass messages between components in a large payment system. However, there are also various “Adapter” that may be used between systems communicating directly with the SAG (Such as SAA or other bespoke/3rd party systems). These are typically the:

  • Remote API Host Adapter (RAHA);
  • MQ Host Adapter (MQHA);
  • Web Services Host Adapter (WSHA).

Having identified that MQ was in use, my initial assumption was that there was most likely a dedicated Queue Manager (QM) server somewhere hosting various swiftnet fin error codes that systems push and pull messages from? However, due to SWIFT CSP requirements, this would most likely - at a minimum - take the form of two Queue Managers. One which manages the queues within the SWIFT Secure Zone, and another that manages queues for the general corporate network and back office systems.

Let's update that diagram to track / represent this understanding:

SWIFT Architecture 02 Dark4

Now I could research how this "messaging" worked!

There are multiple ways to configure Message Queues architectures, in this case there were various dedicated input and output queues for each system, and the message flow looks something like this:

SWIFT MQ 01 Dark2

Full disclosure, swiftnet fin error codes, turns out it’s hard to draw an accurate - yet simple - MQ flow diagram (that one swiftnet fin error codes basically my 4th attempt). So it’s. accurate "enough" for what we needed to remember!

Now I had a good understanding of how it all worked, it is time to define my goal: "Place a payment message directly on to a queue, and have it successfully processed by all downstream systems".

This sounds simple, swiftnet fin error codes, just write a message to a queue, right? But there are a few complications!

  1. Why are there few indications of this attack vector in the wild?
  2. How do I swiftnet fin error codes gain “write” access to the right queue?
  3. What protects the message on the queues?
  4. What protects the messages in transit?
  5. What format are the messages in?
  6. What is the correct syntax for that message format at any particular queue (0 margin for error)?
  7. Where does PKI come in? How / where / when are the messages signed?
  8. Can I somehow get around the message signing?
  9. What values in the messages are dependent / controlled / defined by the system processing them (out of my control)?
  10. What is the maximum amount I can transfer using Straight Through Processing, without alerting the institution / requiring manual validation?

But OK, there's no point dwelling on all of that right now, I'll just clearly define what I want to do!

The goal:

  1. Successfully write a payment instruction for 500,000 GBP;
  2. Inject that message directly onto a specific queue;
  3. Have the message pass environment-specific validation rules;
  4. Have the message pass sanctions and AML checks.
  5. Have the message successfully signed;
  6. Have the message pass SWIFTNet-specific validation rules;

What I was not interested in doing for this research - yet needed to understand nevertheless for a full attack chain was:

  1. How to compromise the institution's network;
  2. How to gain access to the MQ admin's workstation;
  3. How to obtain the pre-requisite credentials.

What I wanted to 100% avoid at all costs:

  1. The attack involving SWIFT payment operators in any way;
  2. The attack involving SWIFT application access in any way;
  3. A need to compromise signing keys / HSMs;
  4. A need to compromise SWIFTNet operator accounts or certificates or any type of PKI.

Now I had an idea of what to do, I needed to make sure I could write a raw MT103 payment instruction! Typically, even when operators write payment messages using a messaging interface application like Alliance Access, they only really write the message “body” via a nice GUI. As raw data this could look something like:

:20:TRANSACTIONRF103
:23B:CRED
:32A:200102GBP500000,00
:33B:GBP500000,00
:50K:/GB22EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59K:/FR20FBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, PARIS, FR
:70:12345-67890
:71A:SHA

I'll break this down in the following table:

NameFieldValue
Transaction Reference20TRANSACTIONRF103
Bank Operation Code23BCRED (Message is to "credit" some beneficiary)
Value Date / Currency / Amount32A200102 (02/01/2020) GBP 500,000.00
Currency / Original Credit Amount33BGBP 500000,00 (£500,000.00)
Ordering Customer50KGB22EBNK88227712345678 (IBAN)
JOHN DOE (Name)
JOHN'S BUSINESS LTD (Line 1)
21 JOHN STREET, LONDON, GB (Line 2)
Beneficiary59KFR20FBNK88332287654321 (IBAN)
ALICE SMITH (Name)
ALICE'S COMPANY (Line 1)
10 ALICE STREET, PARIS, FR (Line 2)
Remittance Information7012345-67890 (essentially a payment reference)
Details of Charge71ASHA (Shared charge between sender and receiver)

Now as this is a valid message body, if I were targeting a payment operator on SWIFT Alliance Access, I could - for the "most" part - simply paste the message into SAA's raw message creation interface and I'd be pretty much done. With the exception of adding the sender / recipient BIC codes and most likely selecting a business unit. However, these values are not stored in the message body.  

Not stored in the message body you say? Well that complicates things! Where are they stored exactly?

The message “body” is referred to as “block 4” (aka the “Text Block”) within the SWIFT MT standard. As suggested by the name, there is probably also lokaler terrorismus - was ist das? block 1-3. This is correct; and these blocks are typically generated by the payment processing applications - such as SWIFT Alliance Access - and not necessarily input by the operators. A "complete" MT103 message consists of 6 blocks:

  • Block 1 – Basic Header
  • Block 2 – Application Header
  • Block 3 – User Header
  • Block 4 – Text Block
  • Block 5 – Trailer
  • Block 6 – System block

So it looked like I was going to need to learn how to craft these various “blocks” from scratch.

Block 1 (Basic header)

Reading through some documentation, swiftnet fin error codes, I crafted the following “Basic header” block:

{1:F01EBNKGB20AXXX0000999999}

A breakdown of what this translates too is as follows:

NameValueContext
Basic Header Flag1Block 1 (Not 2, 3, 4, or 5)
Application TypeFFIN Application
Message Type0101 = FIN (I.e not ACK/NACK)
Sender BICEBNKGB20EBNK (Bank Code) GB (Country Code) 20 (Location Code)
Sender Logical TerminalATypically A, unless they are a significantly large institution and require multiple terminals
Sender BranchXXXAll X if no branch needed
Session Number0000The session number for the message
Sequence Number 999999The sequence number of the message

Taking a step back, swiftnet fin error codes, I already identified two potential problems: the “session” and “sequence” numbers! These are described as follows:

  • Session Number – Must also equal the current application session number of the application entity that receives the input message.
  • Sequence number – The sequence number must be equal to the next expected number.

Hmmm, at this point I was not sure how I could predetermine a valid session and/or sequence number - considering they seemed to be application and "traffic" specific? But there was nothing I could do at the time, so I noted it down in a list of "issues/blockers" to come back to later.

Block 2 (Application Header)

A bit more dry reading later, I managed to also throw together an application header:

{2:I103FBNKFR20XXXXN}

Again, I’ve broken this down so it makes sense (if it didn’t already; I’m not one to assume):

NameValueContext
Application Header Flag2Block 2
I/O IdentifierIInput Message (a message being sent)
Message Type103103 = Single Customer Credit Transaction
Recipient BICFBNKFR20FBNK (Bank Code) FR (Country Code) 20 (Location Code)
Recipient Logical TerminalXAll General Purpose Application Messages must use "X"
Recipient BranchXXXAll General Purpose Application Messages must use "XXX"
Message PriorityNNormal (Not Urgent)

Awesome! No issues crafting this icq system error code 10053 At this point I should probably mention that these BIC codes are not "real", however are accurate in terms of in format and length.

Block 3 (User Header)

The third block is called the “User Header” block, which can be used to define some “special” processing rules. By leverage this header, I could specify that the message should be processed using “Straight Through Processing” (STP) rules which essentially attempts to ensure that the message is processed end-to-end without human intervention. This could be specified as follows:

{3:{119:STP}}

However, this was not yet a valid header! As of November 2018 the user header requires a mandatory “Unique end-to-end transaction reference” (UETR) value, which was introduced as part of SWIFT's Global Payments Innovation haspflt.sys cant start driver - error 2 (gpi)!

This is a Globally Unique Identifier (GUID) compliant with the 4th version of the generation algorithm used by the IETF standard "RFC4122", swiftnet fin error codes. This consists of 32 hexadecimal characters, divided into 5 parts by hyphens as follows:

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

where:

  • x – any lowercase hexadecimal character;
  • 4 – fixed value;
  • y – either: 8, 9, a, b.

This value can be generated using Python as seen below:

$ python -c 'import uuid; id = uuid.uuid4(); print "Value:", id; print "Version:", id.version, id.variant'
Value: 8b1b42b5-669f-46ff-b2f2-c21f99788834
Version: 4 specified in RFC 4122

With an acceptable UETR generated, this is how the third block looked:

{3:{119:STP}{121:8b1b42b5-669f-46ff-b2f2-c21f99788834}}

And as before, a breakdown can be found below:

NameValueContext
User Header Flag3Block 3
Validation Flag119Indicates whether FIN must perform any type of special validation
Validation FieldSTPRequests the FIN system to validate the message according to the straight through processing principles
UETR Field121Indicates the Unique end-to-end transaction reference value
UETR Value8b1b42b5-669f-46ff-b2f2-c21f99788834Unique end-to-end transaction reference used to track payment instruction

Block 5 and 6 (Trailer and System Blocks)

I’ve already discussed “block 4” (the message body), so to wrap this section up, I'll be looking at the final 2 blocks: Block 5, aka the “Trailer”; and block S, aka the “System” block.

Before going forward, let me take a moment to explain the pointlessly complicated concept of input and output messages:

  • An “input” message (I) is a message which is traveling “outbound” from the institution. So this is a message being “input” by an operator and sent by the institution to another institution.
  • An “output” message (O) is a message which is traveling “inbound” to the institution. So this is a message being “output” by SWIFTNet and being received by the institution.

OK, moving swiftly (aaaahhhhh!) on.

For Input messages, these blocks were not too much of a problem. The headers only really seemed to be used to flag whether the message was for training / testing or to flag if it was a possible duplicate, which syntactically took the following form:

{5:{TNG:}}{S:{SPD:}}

Where “TNG” indicated “training” and “SPD” indicated “possible duplicate”.

However, with Output messages, it got considerably more complicated. An example of what the trailer and system block could look like on an Output message is the following:

{5:{MAC:13461AEF}{CHK:4A3367FD3D76}{TNG:}}{S:{SPD:}{SAC:}{COP:P}
{MDG:5E87F8F390E5FB886E8311E4D7C994371FA9AF3119B2C314DAE458738AFF08AC}}

A breakdown of these various values is:

Trailer ({5:)
MAC – Message Authentication Code calculated based on the entire contents of the message using a key that has been exchanged with the destination bank and a secret algorithm;
CHK – This is a PKI checksum of the message body, used to ensure the message has not been corrupted in transit;
TNG – A flag to indicate that the message is a Testing and Training Message.

System ({S:)
SPD – Possible Duplicate Flag
SAC – Successfully Authenticated and Authorized Flag. This is only present if:

  1. Signature verification was successful.
  2. RMA (Relationship Management Application) authorization and verification was successful.

COP – Flag indicating that this is the primary message copy;
MDG – The HMAC256 of the message using LAU swiftnet fin error codes, these seemed to only be values I would need to consider if I was to try and forge an “incoming” message from SWIFTNet or an "outbound" message on the output of the SAG.

So. I'll stick with crafting an “input" message trailer:

{5:{TNG:}}{S:{SPD:}}

Now, having said all that, it turned out the trailer block did seem adsl ber test error ratio sometimes hold 79.00fe printer error MAC code and a message checksum (sigh), meaning I actually needed to construct something like:

{5:{MAC:XXXXXXXX}{CHK:XXXXXXXXXXXX}{TNG:}}{S:{SPD:}}

So that was +2 to my "issues/blockers" list. However, issues aside, I now understood the complete message format, and could put it all together and save the following as a draft / template MT103 message:

{1:F01EBNKGB20AXXX8888999999}
{2:I103FBNKFR20XXXXN}
{3:{119:STP}{121:8b1b42b5-669f-46ff-b2f2-c21f99788834}}
{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200102GBP500000,00
:33B:GBP500000,00
:50K:/GB22EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/FR20FBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, PARIS, FR
:70:12345-67890
:71A:SHA
-}
{5:{MAC:XXXXXXXX}{CHK:YYYYYYYYYYYY}{TNG:}}{S:{SPD:}}

Highlighted in bold above are the areas of the message I was - at this point - unable to pre-determine. Nevertheless, a summary of what that the message describes is:

  • Using the transaction reference “TRANSACTIONRF103”;
  • please transfer 500,000.00 GBP;
  • from John Doe, (IBAN: GB22EBNK88227712345678) at “English Bank” (BIC: EBNKGB20);
  • to Alice Smith (IBAN: FR20FBNK88332287654321) at “French Bank” (BIC: FBNKFR20);
  • Furthermore, please swiftnet fin error codes the transaction charge is shared between the two institutions;
  • and mark the payment with a reference of “12345-67890”.

To wrap up this section, i wanted to take a moment to explain some logic behind the target of 500,000 GBP, as it is also important.

Aside from the many reasons it would be better to transfer [even] smaller amounts (which is an increasingly common tactic deployed by modern threat actors), why not go higher? This is where it’s important to understand the system and environment you are targeting.

In this instance, let's assume that by doing recon for a while I gathered the understanding that:

  • If a message comes from SYS which is over £500k;
  • even if it has been subject to a 4 eye check;
  • and even if it is flagged for STP processing;
  • route it to a verification queue and hold it for manual verification.

This was because a transaction over £500k was determined to be “abnormal” for SYS. As such, if my transaction was greater, the message would not propagate through all systems automatically.

OK, so now that I understood:

  • how the system worked;
  • how it communicated;
  • the fundamental structure of a raw MT103 payment messages;
  • and how much I could reliably [attempt] to transfer.

And with that, swiftnet fin error codes, it was time to take a sui critical error. see debug.log more informations from MT standards and establish an understanding of how I would even get into a position to put this into practice!

To place a message on a queue, I was going to need two things:

  • Access to the correct queue manager;
  • Write access to the correct queues.

Depending on the environment and organisation, access to queue managers could be quite different and complex. However a bare-bones setup may take the following form:

  • An MQ Administrator accesses their dedicated workstation using AD credentials;
  • They then remotely access a dedicated jump server via RDP which only their host is whitelisted to access;
  • This may be required as the queues may make use of Channel Authentication Records, authorizing specific systems and user accounts access to specific queues;
  • The channels may further be protected by MQ Message Encryption (MQME) which encrypts messages at rest based on specific channels. As such, even if someone was a “super duper master admin” they would only be able to read / write to queues specifically allocated win32 disk imager error 8 them within the MQME configuration file (potential target for another time?);
  • The MQ Admin swiftnet fin error codes then use tools such via the Jump Server to read/write to their desired message queues.

So, in this scenario, to gain access to the message queues I - as an attacker - would need to compromise the MQ admin’s AD account and workstations, then use this to gain access to the jump host, from where I could then access the message queues given I knew the correct channel name and was configured with authorization to access it. and maybe throw some MFA in there.

That is understandably a significant requirement! However, when discussion sophisticated attacks against Financial Market Infrastructure (FMI), it is more than reasonable to accept that an Advanced Persistent Threat (APT) would see this as a feasible objective - We don't need to dig into the history of how sophisticated attacks targeting SWIFT systems can be.

Next, it was time to finally identify a feasible attack vector for message forgery.

Now with an idea of how to gain the right access, as well as an understanding of the various technologies and security controls in place; I update my diagram:

SWIFT Security Dark2

You may have noticed I've added something called “LAU” around the SAA-to-SAG adapter, and another “LAU” to the MID-to-SAA MQ channels, which I have yet to explain.  “Local Authentication” (LAU) is a security control implemented by SWIFT to authenticate messages using a pair of shared keys between two systems. These keys are combined and used to generate a SHA256 HMAC of the message and append it to the S block. This can then be validated by error getting flash id recipient system. Effectively, this validates the origin and authenticity of a message. As such, even if an attacker was in position to introduce a fraudulent payment, they'd first need to compromise both the left and the right LAU signing keys, generate the correct HMAC, and append it to the message in order to have it accepted / processed successfully.

But LAU aside, I now just needed to figure out which queue to target! There were a lot of queues to work with as each system essentially has multiple “input” and “output” queues. With that in mind, it was important to note that: an incoming message would require being in swiftnet fin error codes format expected by the target system (from a specific upstream system) and an outgoing message would need to be in the format “produced” by one target system and “expected / ingested / processed” by its respective downstream system. So to figure this out, I worked backwards from the Gateway.

Targeting SAG

This was the least feasible attack vector!

  1. I hadn't really looked into how the SWIFT webmoney error 527 worked - If only I could research literally everything);
  2. SAA and SAG implemented LAU on messages sent between them - An excellent security control!;
  3. The output of SAG was directly on to SWIFTNet which would entail all sorts of other complications - this is an understatement)!

Next!

Targeting SAA

So what if I wanted to drop a message on the “outbound” channel of SAA?

LAU and the SWIFT adapter aside, swiftnet fin error codes, remember those session and sequence numbers? Well, messages which leave SAA are in the near-final stages of their outbound life-cycle, and as far as I understood would need to have valid session and sequence values. Given I didn't know how to generate these values without gaining access to SAA or how they worked in general (and lets not forget the LAU signing) this didn't currently seem feasible.

Next!

Targeting SANCT

This solution didn't actually transport messages back and forth; it just reads messages off the queues and performed checks on their details. Not much I could wanted to leverage here.

Targeting MID

To target MID, I could try and inject a message onto SAA’s “input” queue, or the “output” queue of MID. This would only need to match error message panasonic cs-g120ke air conditioner format of messages produced by the Middleware solution (MID). Following this, in theory, the [mistial] message session and sequence number would be added by SAA, along with the UETR. This was promising!

However, swiftnet fin error codes, MID was a SWIFT “message partner”, which are typically solutions developed using the Alliance Access Development Kit that allows vendors to develop SWIFTNet compatible software, and consequentially, swiftnet fin error codes, implement LAU. So again, swiftnet fin error codes, in-order to forge a message here, I’d need to compromise the left and right LAU signing keys used between SAA and MID, manually HMAC the message (correctly!), and then place it on the correct queue. This also no longer looked promising.

Targeting SYS

OK, how about the input of the next system down - the "Payment System"?

As described previously, the inbound data was a custom “application specific” payment instruction from the institutions back office systems, and not a SWIFT MT message. This would be an entirely new core concept I'd need to reverse - not ideal for this project.

But how about the output queue?

Although SYS received custom format data, I found that it output what seemed to be an initial SWIFT MT messages. This was perfect! Additionally, SYS did not have LAU between itself and MID because (unlike MID) SYS was not a SWIFT message partner, and was just one of many-many systems within the institution that formed their overall payment landscape.

Additionally, swiftnet fin error codes, because SYS was esentially just one small piece of a much larger back office architecture, it was not part of the SWIFT Secure Zone (after all you cant have your entire estate in the Secure Zone - that defeats the purpose) and as such, made use of the Queue Manager within a more accessible section of the general corporate environment (QM1).

With this in mind, and having - in theory - compromised the MQ admin, I could leverage their access to access on the corporate network to authenticate to QM1. I could - in theory -  then write a fraudulent payment message to the SYS “output” queue, which we will call “SYS_PAY_OUT_Q” from here on.

OK! It seems like I finally had an idea of what to do! But before I bios dma error put it into practice, I of course needed to create a diagram of the attack:

SWIFT Attack Dark2

I think it’s important to take a minute to refer back to the concept of “trust” which is what lead to this attack diagram. My theory behind why this may work is because the MID bitmap image not valid error, implicitly trusts whatever it receives from its respective upstream systems. This is intentional, as by design the security model of the payment landscape ensures that: at any point a message can be created, a 4 (or 6) eye check is performed. If there was a system whose purpose it was to ensure the validity of a payment message at any point upstream, the downstream systems should have no real issue processing that message (with some exceptions). After all, It would be next to-impossible to maintain a high-throughput payment system without this design.

And with that said, the plan was now clear:

  • Leverage the access of a Message Queue administrator;
  • to abuse the “trust relationship” between SYS, MID, and SAA;
  • to introduce a fraudulent payment message directly on to the output queue of SYS;
  • by leaning on my new found understanding of complete MT103 payment messages.

It was finally time to try to demonstrate a Proof-of-Concept attack!

So at this point I believe I had everything I needed in order to execute the attack:

  • The target system!
  • The message format!
  • The queue manager!
  • The queue!
  • The access requirements!
  • The generously granted access to a fully functional SWIFT messaging architecture! (that’s a good one to have!)
  • The extra-generously granted support of various SMEs from the target institution! (This was even better to have!)

Message Forgery

I needed to begin by creating a valid payment message using valid details from the swiftnet fin error codes institution. So before moving on I was provided with the following (Note: as with many things in this post, these details have been faked):

  • Debtor Account Details – John Doe, GB12EBNK88227712345678 at EBNKGB20
  • Creditor Account Details – Alice Smith, GB15EBNK88332287654321 at EBNKGB20

Some of you may have notice that the sending and receiving BIC’s are the same. This was because, for the sake of the research, swiftnet fin error codes, I wanted to send the message back to the target institution via SWIFTNet so that I could analyse its full end-to-end message history. Furthermore, you may have noticed we are using "test & training" BIC code (where the 8th character is a 0) - this was to make sure, you know, that I kept my job.

But yes, with access to these "valid" account details and the knowledge gained during the research so far, I could now forge a complete Input MT103 messages:

{1:F01EBNKGB20AXXX0000000000}
{2:I103EBNKGB20XXXXN}
{3:{119:STP}{121:eb02c40e-e060-400a-ac74-47f076dd26e3}}
{4:
:20:TRANSACTIONREF103
:23B:CRED
:32A:200103GBP500000
:33B:GBP500000
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}{5:{TNG:}}{S:{SPD:}}

Note: Field 33B is actually an optional field, however, the MT standard stated that “If the country codes of both the Sender’s and the Receiver’s BIC belong to the country code list, then field 33B is mandatory”. As such, if 33B was not present in the message, it would fail network validation rules and SWIFTNet would return a NAK with the error code: D49.

Optional / Mandatory fields aside, it was not quite that simple! There were a few minor changes I needed to make based on the specific point in the message's its life-cycle I was planning to introduce it!

As I list these changes, swiftnet fin error codes, remember that the objective is to swiftnet fin error codes the message to the output queue of SYS (Which exists before MID, SAA and SAG)

  1. The first 3 blocks needed to be placed on a single line;
  2. Remove field 121 (UETR) from the User Header, as this would be generated by SAA during processing;
  3. Remove 1 character from the transaction reference as it needed to be exactly 16 characters (classic user error);
  4. Add decimal point to transaction amount using a comma - otherwise it would fail syntax validation rules;
  5. Ensure the IBAN's were real and accurate, otherwise it seemed the message would fail some type of signature validation on the SWIFT network. The IBANs are fake here, but during swiftnet fin error codes real PoC we used accurate account details in collaboration with the target institution;
  6. Remove the trailer block (5) - as this would be appended by SAA during processing;
  7. Remove the System Block (S) - as this would be completed by the SAG.

And the final message was as follows:

{1:F01EBNKGB20AXXX8888999999}{2:I103EBNKGB20XXXXN}{3:{119:STP}}{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200103GBP500000,00
:33B:GBP500000,00
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}

Note that the location in which I introduce the message has resolved all of the "issues / blockers" I'd tracked whilst researching the message structure! It would seem the further upstream swiftnet fin error codes go, the easier the attack becomes - given MQ is still used as a transport medium.

Message Injection

Now I had my raw MT103 message, I just need to save it to a file (“Message.txt” - sure why not) and place onto the “SYS_PAY_OUT_Q” queue using one of the admin's tools:

  1. With access to a sole MQ Administrator's AD account;
  2. We connect to the MQ admins machine;
  3. Log into the Jump Server;
  4. Open our MQ tools of choice and authenticate to queue manager (QM1) where the output queue for SYS was managed;
  5. Connected to the "SYS_PAY_OUT_Q" queue;
  6. Selected my forged “Message.txt” file;
  7. Invoked the “write to queue” function;

And it was off!

Loggin in to Alliance Access and opening the message history tab, we sat awaiting for an update. Waiting, waiting, waiting… waiting… and.

ACK! It worked!

That's a joke; did we hell receive an ACK!

See, this last section is written slightly more "linear" than what actually happened. Remember those "tweaks" used to fix the message in the previous section? I hadn't quite figured that out yet.

So roughly seven NACKs later - each time troubleshooting and then fixing a different issues - we did indeed, see an ACK! The message was successfully processed by all systems, passed target system validation rules, passed sanctions and AML screening, passed SWIFTNet validation rules, and SWIFT’s regional processor had received the message and sent an "Acknowledgement of receipt" response to the sending institution!

For the sake of completeness, I’ve included the ACK below:

{1:F21EBNKGB20AXXX1947392344}{4:{177:2001031102}{451:0}}

And of course a breakdown of what it all means:

NameValueContext
Basic Header Flag1Block 1
Application TypeFF = FIN Application
Message Type2121 = ACK
Institution CodeEBNKGB20AXXXEBNKGB20 (BIC) A (Logical Terminal) XXX (Branch)
Sequence and Session No.19473923441947 (Sequence No.) 392344 (Session No.)
Date Tag177200103 (Date) 1102 (Time)
Accept / Reject Tag4510 = Accepted by SWIFTNet

Excellent! WooHoo! It worked! . That took a lot of time and effort!

Closer Inspection

But the ACK wasn't enough, I wanted to make sure I understood what had happened to the message throughout its life-cycle. From the message I placed on the initial queue, to being processed by SWIFTNet.

Thankfully, as we sent the message back to the target institution we could see its entire message history. I already knew what the raw message placed on the queue looked like, so I wanted to focus on what became of the message once it had been processed by SAA:

{1:F01EBNKGB20AXXX8888999999}{2:I103EBNKGB20XXXXN}{3:{119:STP}{121:b42857ce-3931-49bf-ba34-16dd7a0c929f}}{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200103GBP500000,00
:33B:GBP500000,00
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}
{5:{TNG:}}{S:{SPD:}}
  • The end-to-end tracking UUID had been generated and added (b42857ce-3931-49bf-ba34-16dd7a0c929f) in block 3;
  • The message trailer had been swiftnet fin error codes ({5:{TNG:}}) where I could see that - due to the BIC code used - SAA had flagged the message as "test and training".
  • Additionally, an initial System Block segment had been added ({S:{SPD:}}), tagging the message as a possible duplicate. I wonder why - *cough* 7th attempt *cough*?

OK, so that was SAA. Now let’s see how it looked it once it passed through the Gateway and regional processor:

{1:F01EBNKGB20AXXX1947392344}{2:O1031102200103EBNKGB20AXXX19473923442001031104N}{3:{119:STP}{121:b42857ce-3931-49bf-ba34-16dd7a0c929f}}{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200103GBP500000
:33B:GBP500000
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, swiftnet fin error codes, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}
{5:{MAC:13579112}{CHK:D8E8FCA2DC0F}{TNG:}}{S:{SPD:}{SAC:}{COP:P}}

OK, we can see a few changes now.

  • The session and sequence numbers have been populated (1947392344);
  • The I/O identifier in block 2 has been updated to track that it is now an "Output" message;
  • The additional data within Block 2 is a combination of the input time, date, BIC, session and sequence numbers, output date/time, and priority;
  • The trailer has been updated with a message authentication code (MAC) calculated based on the entire contents of the message using a pre-shared key and a secret algorithm;
  • Additionally, a checksum of the message body has been stored within the trailer’s “CHK” tag. This is used by the network to ensure message integrity.

I also took a look at the entire outbound message history, just to see all the “Success” and “No violation” statements to make it feel even more awesome!

So that's that really.

With a bit of research and support I was able to demonstrate a PoC for introducing a fraudulent payment message to move funds from one account to another, by manually forging a raw SWIFT MT103 single customer credit transfer message, and leveraging various system trust relationships to do a lot of the hard work for me!

As mentioned briefly in the introduction, this is not something I have really seen or heard of happening in practice or in the "wild". Perhaps because it clearly takes a lot of work. and there is a huge margin for error. However, if an adversary has spent enough time inside your network and has had access to the right documentation and resources, this may be a viable attack vector. It definitely has its benefits:

  • No need to compromise multiple payment operators;
  • No requirement to compromise - or establish a foothold within - the SWIFT Secure Zone;
  • No requirement to bypass MFA and gain credentials for a messaging interface;
  • No generation of application user activity logs;
  • No payment application login alerts;
  • No bespoke app-specific and tailored malware;
  • And all the other things associated with the complex task of gaining and leveraging payment operator access.

All an attacker may need to do is compromise one specific user on the corporate network: a Message Queue administrator.

The industry is spending a lot of time and effort focused on securing their payment systems, applications, processes, and users to keep - among other things - payment operators safe, Messaging Interfaces locked down, and SWIFT systems isolated. But the reality is,; the most valuable and most powerful individual in the entire model, might just be a single administrator!

As always, a security model is only as strong as its weakest link. If you're not applying the same level of security to your wider institution, there may very well be many weak links within the wider network which chain together and lead to the comrpomise of systems which feed into your various payment environment.

I think the main thing to remember when reflecting on this research is that it did not abuse any vulnerabilities within the target institution's systems, or even vulnerabilities or weaknesses within the design of their architecture, swiftnet fin error codes. It simply leverages the legitimate user access of the Message Queue administrators and the trust relationships that exist by design within these types of large-scale payment processing systems.

So the harsh reality is, there is no particular list of recommendations for preventing this type of attack in itself. However, the main point to drive home is that you must ensure the security of your users - and overall organisation - is of a high enough standard to protect your highest privileged users from being compromised. Things such as:

  • Strong monitoring and alerting controls for anomalous behaviour;
  • Requirements for Multi-Factor authentication for access to critical infrastructure;
  • Segregation of critical infrastructure from the wider general IT network;
  • Strong password policies;
  • Well rehearsed incident detection and incident response policies and procedures;
  • Frequent high-quality security awareness training of staff;
  • Secure Software Development training for your developers;
  • Routine technical security assessments of all critical systems and components;
  • The use of 3rd party software from reputable and trusted vendors;

However, in the context of Message Queues, there is one particular control which I think is extremely valuable: The implementation of channel specific message signing! This, as demonstrated by SWIFT's LAU control, is a good way in which to ensure the authenticity of a message.

As discussed, LAU is - as far as I know at the time of writing - a SWIFT product / message partner specific control. Error generating image. drupal it's concept is universal and could be implemented in many forms, two of which are:

  • Update your in-house application's to support message signing, natively;
  • Develop a middleware component which performs message signing on each system, locally.

This is a complex requirement as it requires considerable effort on the client’s behalf to implement either approach. However, swiftnet fin error codes, SWIFT provides guidance within their Alliance Access Developers guide on how to implement LAU in Java, Objective C, Scala and Swift;

  1. Strip any S block from swiftnet fin error codes Linker error unable to open file sysinit.obj message input. Keep only blocks 1: through 5;
  2. Use the FIN message input as a binary value (unsigned char in C language, byte in Java). The FIN message input must be coded in the ASCII character set;
  3. Combine the left LAU key and the right LAU key as one string. The merged LAU key must be used as a binary value (unsigned char in C language, byte in Java), swiftnet fin error codes. The merged LAU key must be coded in the ASCII character set;
  4. Call a HMAC256 routine to compute the hash value. The hash value must also be treated as a binary value (unsigned char in C language, byte in Java). The HMAC size is 32 bytes;
  5. Convert the HMAC binary values to uppercase hexadecimal printable characters.

An example of how this may work in the more flexible middleware solution proposed is where the original service is no longer exposed to the network, and is altered to only communicate directly with the custom "LAU-eqsue" service on its local host. Swiftnet fin error codes service would then sign and route the message to its respective queue.

When received, the core of the recipient payment service would seek to retrieve its messages from the queues via the "LAU-esque" signing middleware, which would retrieve the message and subsequently verify its origin and authenticity by re-calculating the signature using their shared (secret) keys. Key-pairs could further be unique per message flow. This design could allow for the signing to be used as a way to validate the origin of a message even if it had passed through multiple [local] intermediary systems.

As a final bit of creative effort, I made yet another diagram to represent what this could perhaps look like - if life was as easy as a diagram:

SWIFT Help Dark

If you made it this far thanks for reading all. ~6k words!? I hope you found some of them interesting and maybe learned a thing or two!

I'd like express our gratitude to the institution who facilitated this research, as well as specifically to the various SMEs within that institution who gave their valuable time to support it throughout.

Fineksus - SWIFT Standard Changes 2019

https://fineksus.com/swift-mt-standard-changes-2019/

Paiementor - SWIFT MT Message Structure Blocks 1 to 5

https://www.paiementor.com/swift-mt-message-structure-blocks-1-to-5/

SEPA for corporates - The Difference between a SWIFT ACK and SWIFT NACK

https://www.sepaforcorporates.com/swift-for-corporates/quick-guide-swift-mt101-format/

SEPA for corporates - Explained: SWIFT gpi UETR – Unique End-to-End Transaction Reference

https://www.sepaforcorporates.com/swift-for-corporates/explained-swift-gpi-uetr-unique-end-to-end-transaction-reference/

M DIBA - LAU for SWIFT Message Partners

https://www.linkedin.com/pulse/lau-swift-message-partners-mohammad-diba-1/

Prowide - About SWIFT

https://www.prowidesoftware.com/about-SWIFT.jsp

Microsoft - SWIFT Schemas

https://docs.microsoft.com/en-us/biztalk/adapters-and-accelerators/accelerator-swift/swift-schemas

SWIFT FIN Guru - 1e stop error windows 7 message block structure

http://www.swiftfinguru.com/2017/02/swift-message-block-structure.html

 

1 Messaging FIN Error Codes This reference guide lists the error codes and abort notifications returned by FIN in case of message validation swiftnet fin error codes or other conditions such as protocol violations or delivery issues. 22 July 2016

2 FIN Table of Contents Preface. 4 About this document. 4 Audience. 4 Significant changes. 4 Chapter 1 Introduction. 5 Chapter 2 Numeric Codes General Logout/Quit Acknowledgement Errors Re-Login Request Errors Retrieval Errors Message Status Abort Reasons FIN and General Purpose Application Session Termination Report Errors Bulk Retrieval Errors Codes Chapter 3 Alphanumeric Codes General A Codes - Re-select Error Codes B Codes - Copy Swiftnet fin error codes Errors C, D, and E Codes - Conditional Semantic Error Codes G Codes - Service-specific Validation H Codes - Basic Header and Application Header Validation K Codes - Code Words Validation in Generic Fields L Codes - LOGIN Errors M Codes - Message Errors N Codes - Market Infrastructure Resiliency Service (MIRS) Errors P Codes - Protocol Errors R Codes - Re-login/Re-select Errors S Codes - System-initiated Abort Errors S Codes - Select Errors T Codes - Text Validation U Codes - User Header Validation V Codes - System Message Errors and Message Block Format Errors Error Codes

3 Table of Contents 3.18 X Codes - FINCopy Message Validation (01-27) and Delayed NAK Error Codes (30-99) Y Codes - UNK Error Codes Z Codes - Trailer Validation Chapter 4 FIN Errors Introduction Abort Codes Diagnostic Codes for SS Diagnostic Codes for SA Legal Notices July

4 FIN Preface About this document Audience This reference guide lists the error codes and abort notifications returned by FIN in case of message validation errors or other conditions such as protocol violations or delivery issues. This book describes the FIN Error Codes. It should be read by: users who wish to gain an understanding of the FIN service developers who need background information on elements of FIN Swiftnet fin error codes reader is expected to have an understanding of FIN messaging, which is described in the FIN Service Description and the FIN Operations Guide. For more information about the rules, the reader must consult the Message Format Validation Rules. Significant changes The following tables list all significant changes to the content of FIN Error Codes since the 24 July 2015 edition. These tables do not include editorial changes that SWIFT makes to improve the usability and comprehension of the document. New information Swiftnet fin error codes of error codes E20, E88, E98, E99, T49, and T69 swiftnet fin error codes longer available) Addition of error code G27 Addition of error code U12 Location Error codes E20, E88, E98, E99, T49, and T69 G27 U12 Updated information Update text of error codes B05, C06, C08, C20, C28, C38, C39, C41, C71, C72, D07, D24, D31, D45, D59, D99, E04, E34, E39, E41, E42, E77, E78, E80, T09, T14, T22, T26, T39, T66, T94, T95, T96, swiftnet fin error codes, U00, U09, X20, swiftnet fin error codes, and X35 Location Section 3.3, B Codes swiftnet fin error codes Copy Service Errors Section 3.4.1, C Error Codes Section 3.4.2, swiftnet fin error codes, D Error Codes Section 3.4.3, E Error Codes Section 3.15, T Codes - Text Validation Section 3.16, U Codes - User Header Validation Section 3.18, X Codes - FINCopy Message Validation (01-27) and Delayed NAK Error Codes (30-99) 4 Error Codes

5 Chapter 1 Introduction Chapter 1 Introduction The FIN error codes are divided into the following groups: Validation error codes Conditional semantic error codes Abort error codes All input messages are validated for syntax and semantic errors by the system. If there is an error, a validation error code is returned in the logical (negative) acknowledgement or in an MT 019 Abort Notification. Abort error codes give the reason why an application or the logical connection has been discontinued. They are generated following the recognition of a certain condition and not necessarily due to errors in a message. Abort error codes can come from the system or from a user's terminal. For reference purposes, the error codes have been placed in two chapters. Chapter 2, Numeric Codes, contains all the errors that are represented by two- or three-digit codes. Error codes in Chapter 3, Alphanumeric Codes, have the following format: <code><nn> where <code> is a letter designating the error type and <nn> identifies the particular error. Where two or more variants of a message exist, for example, MT 103, MT 103 STP, swiftnet fin error codes, and MT 103 REMIT, each variant is referenced independently in an error code description. This means that mention of the MT 103 refers only to the generic variant of the MT 103 and does not include either the MT 103 STP or the MT 103 REMIT. 22 July

6 FIN Chapter 2 Numeric Codes 2.1 General Numeric codes are used for: Logout/Quit Acknowledgement errors (field 401) Re-Login Request errors (fields 280, 331 and 333) Retrieval errors (field 421) Message status (field 431) Abort reasons (field 432) FIN and General Purpose Application session termination (field 443) Report errors (field 461) 2.2 Logout/Quit Acknowledgement Errors The following error codes are returned in field 401 of Logout and Quit acknowledgements. Logout and Quit Commands are always positively acknowledged and the session (General Purpose Application or FIN) closed. However, one of the following error codes can be included in the acknowledgement. 01 Incorrect time/day The Logout Command can include the time/day inhibitor which prevents the next Login occurring before the time/day specified. The time/day in pdweb error could not start server format DDHHMM cannot be more than 7 days after the current date. 02 Training trailer missing The trailer block is only present if the message is sent by a training logical terminal. If the Logout Command is sent from a training logical terminal, it must contain a Training trailer. 03 Input sequence number error Each message sent from a logical terminal has an input sequence number. The first message sent in the General Purpose Application will always have an input sequence number ofwhereas the first message sent in FIN will have an input sequence number value of the last input sequence number+1 sent from that logical terminal. This error will be returned in the acknowledgement of a Logout or Quit Command when the input sequence number of that command is incorrect. 2.3 Re-Login Request Errors The following error codes are returned in fields 331, and 333 of acknowledgements, session history reports, black-to-white error .asp id daily check reports: 010 Re-Login Request received while logical terminal is active on the Logical Terminal Control association 6 Error Codes

74 Retrieval Errors The following codes are returned in field 421 of message retrievals: 000 Message has no text block 002 Message was encrypted and no key or the wrong key was supplied by the user 22 July

8 FIN 003 Empty report (no messages found) 004 Logical terminal is not authorised to retrieve the message, that is the requester is neither the sender nor the receiver of the original message 005 Text lost due to Slice Processor recovery 006 History lost due to Slice Processor recovery 007 Local data error while talking to smtp.mail.ru message is a retrieval report (MTs 021 or 023) 010 Invalid MT received by Slice Processor pseudo logical terminal (system) swiftnet fin error codes Invalid <application-id> received by Slice Processor pseudo logical terminal (system) 012 Invalid date in retrieval criteria tag (system) 013 Invalid time in retrieval criteria tag (system) 014 End daytime before start daytime 015 Target message older than 124 days (for range retrieval, daytime used) 016 <branch-code> is not 'XXX' 018 Invalid destination for report (tag 102). The logical terminal must have the same destination as the sender of the retrieval request or be a SWIFT logical terminal, and must be enabled for the application in which the retrieval message is to be sent 019 Invalid input retrieval by receiver or output retrieval by sender (only single message input reference/message output reference allowed) 020 Invalid synonym retrieval (synonym is not sender or receiver of message) 021 Unknown target logical terminal 022 Request received at wrong Slice Processor (system) 023 Could not retrieve message input reference in message output reference retrieval (system) 032 No delivery attempt in message input reference retrieval by receiver 033 On-line text read error (system) 034 On-line history read error (system) 8 Error Codes

9 Chapter 2 Numeric Codes 035 Text read error from archival (system) 036 History read error from archival (system) 037 Partial report - major system recovery in progress 038 Unable to retrieve text and history from archival because of system problems 040 The limits for group retrieval (99 messages in one request) have been exceeded 041 Message could not be decrypted (system) 043 The logical terminals in the beginning message input reference/message p-cad 2006 error 5566 reference and the ending message input reference/message output reference in a range retrieval request are not the same, in tag 252 (message input reference range) or 254 (message output reference range) 044 Illogical use of field 152 <1st-isn> or field 153 <1st-osn>. input sequence number or output sequence number already included as component in message input reference(s) or message output reference(s) 045 Message text not retrievable (message not successfully delivered) 046 Off-line retrieval not allowed for Test and Training messages 047 The text of local test mode messages is not retrievable 048 Retrieval message too long 049 Retrieval period specified exceeds 10 days 099 Retrieval report problem. Contact your Customer Support Centre 2.5 Message Status The message status is returned in field 431 of non-delivery warnings, undelivered message reports, and retrieved messages. 01 Delivered 02 Rejected by destinee 04 Aborted 22 July

10Abort notification MT 019 contains an alphanumeric abort code 10 Error Codes

11 Chapter 2 Numeric Codes These codes are specific to each FINCopy service. Contact your respective service provider for the meaning of each code within the range For Euro Banking Association (EBA) Processing, only the following codes are used: 70 Refusal from the Clearing Computer, and delivery aborted; the Sender of the payment message should also receive an MT 998 / SMT n75 Error Message from the Clearing Computer giving further reasons for the refusal. 71 Refusal from the Clearing Computer because of a message format error that prevented normal processing, and delivery aborted. 99 System error 2.6 Abort Reasons The following codes are returned in field 432 of abort notifications and, for the FINCopy service, Message Refusals: 01 Message too old (remained undelivered for n days) 02 Too many unsuccessful delivery attempts 03 Destination disabled 04 Operator aborted 05 Message could not be recovered after a major system failure because it was user encrypted 06 Message type incompatible with the FIN interface mode 11 Message is too old, but was authorised 12 Too many delivery attempts, but message was authorised 13 Destination is disabled, but message was authorised 14 Message is too long, but was authorised 21 Message is too old and was bypassed 22 Too many delivery attempts and the message was bypassed 23 Destination is disabled and the message was bypassed 24 Message is too long and was bypassed 22 July

12 FIN 29 Message held for approval prior to Bypass mode and aborted 32 Message is too old and was not authorised 33 Copy message to the copy service server was aborted 35 FINCopy service parameter(s) incorrectly defined in FIN 50-ZZ 99 is pre-defined as 'system error'. All other alphanumeric codes (combination of 0-9 and A-Z) are specific to each FINCopy service. Contact your respective service provider for the meaning of each code. Code S1 is used by the Sanctions screening service to indicate that the message has been aborted on request of the subscribing user. Note: All undefined numeric codes are reserved for use by FIN. 2.7 FIN and General Purpose Application Session Termination The following codes are returned in field 443 of Service Message 14 (for further details see FIN System Messages): 000 Normal termination 001 Application Control or Logical Terminal Control has aborted 002 Application Control or Logical Terminal Control has terminated normally 004 System timed out message output reference ACK 006 QUIT or LOGOUT received while outstanding input messages 007 Input message/service message after reception of a QUIT or LOGOUT 008 Input window violation (more outstanding input messages than window size) 009 System timed out swiftnet fin error codes association establishment 010 Reception of a SELECT from a logical terminal that already has a FIN session 011 Association establishment request php error logs centos authentication 014 Message output reference ACK Basic Header error 015 Too many messages input in a session. Maximum is Error Codes

13 Chapter 2 Numeric Codes 016 Too many messages output in a session. Maximum is Message output reference ACK from wrong synonym 025 As for 052 but due to receipt of a Re-Login Request, rather than a Login Request 051 As for 052 but on a different Regional Processor 052 Reception of a login from a logical terminal for which the system has already processed a swiftnet fin error codes transmitted over a different Logical Terminal Control on the same Regional Processor. The existing session is aborted and the new session established. 053 SELECT with bad text block 054 AP ABORT REQUEST with bad text block 2.8 Report Errors The following codes are returned in field 461 of Delivery Subset Status Reports, Undelivered Message Reports, and Undelivered SSI Update Notification Reports: 001 Empty report 002 End of undelivered report 003 System undergoing major recovery or system not completely synchronised yet 004 Too many undelivered messages 005 User on fall back Regional Processor, cannot generate report 006 The message referenced in the request could not be found. 007 Invalid destination for report. The sender of the request must be the same as the sender of the message referenced in the request. 008 No MTs 671 were found for the referenced MT Requesting logical terminal in invalid state 016 Branch code is not "XXX' 099 System internal problems, contact your Customer Support Centre 22 July

14 FIN 2.9 Bulk Retrieval Errors Codes The following codes are returned in field 144 of Bulk Retrieval Responses (MT 025): 03 Retrieval only partially complete 11 Invalid <start-date-time> 12 Invalid <end-date-time> 13 Invalid retrieval time range 14 Retrieval aborted due to system error 15 Retrieval aborted due to communication error 16 Retrieval aborted due to system recovery 17 Retrieval aborted by SWIFT 19 Retrieval complete The text of messages that were sent to the retrieving BIC more than 124 days ago cannot be retrieved. If those messages were received by the retrieving BIC less than 124 days ago, the file contains the message output reference of the history and the message input reference of the text. 20 Retrieval aborted due to system error (Test and Training destination - attempt to use tape) 21 Retrieval aborted due to system error (FIN/FIN Bridge key error) 22 Retrieval aborted due to system error (missing master BIC) 14 Error Codes

15 Chapter 3 Alphanumeric Codes Chapter 3 Alphanumeric Codes 3.1 General This chapter contains the codes for the following error types: Code Error Type Code Error Type A Abort at Application Interface Level Errors P Protocol Errors A Re-select Errors R Re-login/Re-select Errors B Copy Service Errors S System-initiated Abort Errors C Dialout Errors S Select Errors C, D and E Conditional Semantic Errors T Text validation (Block 4) Errors G Service-specific Validation Errors U User Header Validation Errors H Basic Header and Application Header Validation Errors U User Abort Errors K Code Words Errors in Generic Fields V System Message or Message Block Format Errors L LOGIN Errors X Delayed NAK Errors and FINCopy Service Message Refusals M Message Errors Y User Negative Acknowledgement Errors N Market Infrastructure Resiliency Service (MIRS) Errors Z Trailer Validation Errors Note: Similar error codes are used by other SWIFT services, such as Accord, or Processing for Euro Banking Association (EBA), and can have different meanings. The error codes used by each of the services are described in the respective service documentation. 3.2 A Codes - Re-select Error Codes A56 Re-select NAK error code (in field tag 503) to indicate that the logical terminal is not in a recoverable state. The FIN interface should execute a fresh select procedure. 3.3 B Codes - Copy Service Errors B01 Message contains Value-Added Service server id but sender or receiver, or both, are not members of the service. B02 Available. B03 103:TPS is present in the message but the sender is not a member of TPS, or the message is not allowed for TPS. 22 July

16 FIN B04 Available. B05 A system error has occurred. Contact your local Customer Support Centre for further information. 3.4 C, D, and E Codes - Conditional Semantic Error Codes Note Where a natural language expression would be too difficult to synthesise or too long, a matrix is provided. The row and column headers identify the elements involved (for example, field tags, swiftnet fin error codes, code words, letter options). Matrices should be read from left to right and from top centos setuproot error mounting /proc bottom C Error Codes C00 Not used. C01 MTs 102, 102 STP, 104, and 107 If field 19 is present in sequence C, then it must equal the sum of the amounts in all occurrences of field 32B in sequence B. MTs 201, 203, 204, and 559 The amount in field 19 must equal the sum of the amounts in all occurrences of field 32B or 34A. MT 256 If field 19 is present in sequence C, then it must equal the sum of the amounts in all occurrences of field 32J in sequence B. MT 824 Field 19 at the completion of each outer repetitive sequence must equal the sum of the products of subfields 1 and 3 in all occurrences of field 68A from its respective inner repetitive sequence(s). C02 The orton 9600 + dns error code must be the same for all swiftnet fin error codes of indicated fields in the entire message. See the Standards MT Message Reference Guides for the indicated fields in each message. Examples: The following list (not exhaustive) explains how error code C02 is applied in specific message types: MT 321. The currency code in the amount fields (fields 19A in sequence B) must be the same for all occurrences of this field in the message. MTs 320 and 330. The currency code in the amount fields, except for fields 33B and 33E in sequence G, must be the same for all occurrences of these fields in the message. MT 350. The currency code in the amount fields 32B and 34B in sequence B must be the same. 16 Error Codes

17 Chapter 3 Alphanumeric Codes Special Cases: The following MTs (not an exhaustive list) apply error code C02 in an exceptional manner (for example, either based on the presence of another field OR individually to separate groups of fields within the MT): MTs 103, 103 REMIT, and 103 STP. If field 71G is present, the currency code in the fields 71G and 32A must be the same. MTs 104 and 107. The currency code in fields 32B and 71 G in sequences B and C must be the same for all occurrences of these fields in the message. The currency code in field 71F in sequences B and C must be the same for all occurrences of this field in the message. MT 320. The currency codes in the amount fields 32B, 32H, and 34E in sequence B, and field 71F in sequence H, must be the same. MT 620. If field 32H is present, then the currency code must be the same as the currency code in field 32B. C03 The number of decimal digits in the amount component is checked against the maximum allowed for the corresponding currency. This check is mostly applied to fields that contain both the amount and the currency code components. Examples: field 32A in MTs 103, 103 REMIT, 103 STP and in MT 256, sequence C field 32B in MTs 104 and 107, sequences B and C This check also applies, among others, to: field 19 in MTs 102, 102 STP, 104, 107, 201, 203, 204, and 559 where the corresponding currency is the one used in swiftnet fin error codes 32B or 34A field 19 in MT 824 where the corresponding currency is the one used in corresponding occurrences of field 68A field 32J in sequence B, and to field 19 in sequence C, in MT 256 where the corresponding currency is the one used in field 32A field 33B in MTs 103, 103 REMIT, 103 Swiftnet fin error codes and in MTs 104 and 107, sequence B field 71F in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequences B and C field 71G in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequences B and C field 72 Reject/Return in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequence A Note: Error code C03 should be applied only to field 68A in MT 824 if subfield 5 is present. C04 MTs 503, 504, and 506 In sequence B, if field :19B::TEXA is not present, swiftnet fin error codes, then field :19B::TCRL is mandatory; otherwise field :19B::TCRL is optional. Sequence B If field :19B::TEXA is. Then field :19B::TCRL is July

18 FIN C05 Identifier Code must be a financial institution BIC. This error code applies to borland error f1004 types of BICs referenced in a FIN message, including connected BICs, non-connected BICs, Masters, Synonyms, Live destinations and Test & Training destinations. Waitformultipleobjects returns error_invalid_handle the table below for the list of MTs affected. MT Field Sequence(s) Qualifier Comments A 56A 57A 52A A, B B B A, B 53A 54A 57A C C B The same validation applies to the MT 102 and the MT 102 STP A 53A 54A 55A 56A The same validation applies to the MT 103, MT 103 REMIT, and the MT 103 STP 57A A 53A 57A A, B C B Note: For sequence C, see also error code C A A, B 53A C 57A B A 53A 54A 111, A 200,A 57A 52A 53A 54A 56A 57A 18 Error Codes

19 Chapter 3 Alphanumeric Codes MT Field Sequence(s) Qualifier Comments 58A 202 COV COV A 53A 54A 56A 57A 58A 52A 56A 57A 53A 57A 58A 52A 53A 56A 57A 58A 52A 53A 56A 57A 58A 52A 56A 57A 51A 52A 52G 56A 57A 58A A A A A A A B B B B A A A A A A A B B B A A A B B B A 22 July

20 FIN MT Field Sequence(s) Qualifier Comments 56A A C AJ 56AJ 57AJ 53AJ 56AJ 57AJ 53AJ 56AJ 57AJ 53A 56A 57A 53AJ 56AJ 57AJ 84AJ 86AJ B1, B2, swiftnet fin error codes, D B1, B2, swiftnet fin error codes, D B1, B2, D D1, D2, D3 D1, D2, D3 D1, D2, swiftnet fin error codes, D3 B, E B, E B, E C, E, L C, E, L C, E, L B C, E, L P B3a CDEA INTE ACCW 95P D1 CDEA INTE ACCW AJ 56AJ 57AJ 86AJ C, D, E, swiftnet fin error codes, F, I C, D, E, F, I C, D, E, F, I C, D, E, swiftnet fin error codes, F, I P C1 CDEA INT2 INTE ACCW AJ 56AJ 57AJ 86AJ 53AJ 56AJ C, D, E, F C, D, E, F C, D, E, F C, D, E, F C, D, F C, D, F 20 Error Codes

21 Chapter 3 Alphanumeric Codes MT Field Sequence(s) Qualifier Comments 341, AJ 86AJ 53AJ 56AJ 57AJ 86AJ 53A 56A 57A 86A C, D, F C, D, F C C C C D, G, L, M D, G, L, swiftnet fin error codes, M D, G, L, M D, G, L, M A D, G, K, L, M, N 56A D, G, K, L, M, N 57A D, G, K, L, M, N 86A D, G, K, L, M, N A 56A 57A 86A 53A 56A 57A 86A 53A 56A 57A 86A C, E C, E C, E C, E L, M L, M L, M L, M J, K, L, M J, K, L, M J, K, L, M J, K, L, M P B1 ACCW INT1 INT A 53A 54A 57A 22 July

22 FIN MT Field Sequence(s) Qualifier Comments 58A A A 450, 455, A P C2 ACCW INTM PAYE P C2a1, E1 ACCW INTM PAYE P B2a1, D1 ACCW INTM PAYE P B1b1 ACCW INTM PAYE P D2 ACCW INTM PAYE P C2 ACCW INTM PAYE P D2 ACCW INTM PAYE A B P C2 ACCW INTM PAYE 540, 541, 542, 543, 544, 545, 546, P E2 ACCW INTM PAYE A P D2a ACCW P E2 ACCW INTM PAYE A 56A 57A 86A 87A 53A 56A 57A 86A 87A 86A 87A B B, C B, C B, C B, C 22 Error Codes

23 Chapter 3 Alphanumeric Codes MT Field Sequence(s) Qualifier Comments A 87A A A 53AJ 56AJ 57AJ 86AJ C, D, E, F C, D, E, F C, D, E, F C, D, E, F A B, C A B A C P B1 ACCW INT1 INT A 42A 51A 53A 57A A 57A A A 42A 51A 52A 53A 57A A 42A 52A 57A 730, A A 22 July

24 FIN Win32diskimager error 123 Field Sequence(s) Qualifier Comments 42A 58A A 57A 58A A A 54A A 57A 58A A 54A 768, A 51A 52A 53A 54A A A 53A 54A A A A 56A A n90 n91 52A 52A 57A C06 MT 210 Either field 50a or field 52a, but not both, must be present in a repetitive sequence. 24 Error Codes

25 Chapter 3 Alphanumeric Codes MTs 710 and 720 Either field 52a or field 50B, but not both, must be present. If field 52a is. Then field 50B is. MT 910 Either field 50a or field 52a must be present. C07 MT 516 Either field 35A or 35N must be present, swiftnet fin error codes. C08 In fields listed below, swiftnet fin error codes, the codes XAU, XAG, XPD, swiftnet fin error codes, and XPT are not allowed, as these are codes for commodities for which the category 6 commodities messages must be used. MT Field Sequence(s) B B STP 32B 32A 32B 32A B C B C A 103 REMIT 32A 103 STP 32A A B A 202 COV 32A A B A 205 COV 32A A B B B B 33B 71F 32B B1 B2 C D B B1 22 July

26 FIN MT Field Sequence(s) B 32G 34B 32G 32B 33B 34a 34B 32B 33B 33E 32Q 32E 71F 32H B2 D D E A A A B1 D D E G H K L C09 MT 430 In each occurrence of sequence A, if field 33a is present, then field 32a must be present. C10 MT 422 At least one of the fields 72, 75 or 76 must be present. C11 MT 400 If field 57a is present, fields 53a and 54a must be present. C12 MTs 707 and 747 When field 32B or 33B is present, field 34B must be present. Conversely, when field 34B is present, either field 32B or field 33B must be present. C13 MT 750 If any of fields 33B, 71B, or 73 is present, field 34B must be present. C14 MTs 559 and 754 Either field 53a or 57a, but not both, may be present. C15 MT 747 At least one of the fields 31E, swiftnet fin error codes, 32B, 33B, swiftnet fin error codes, 34B, 39A, swiftnet fin error codes, 39B, 39C, 72, or 77A must be present. 26 Error Codes

27 Chapter 3 Alphanumeric Codes C16 MT 707 If field 23 is present, field 52a must be present. C17 MT 734 If field 73 is present, field 33a must be present. C18 MT 752 If fields 32B and 71B are present, field 33a must be present. C19 MT 754 Either field 72 or field 77A, but not both, may be present. C20 MT 304 In sequence D, field 30F may only be present if field 34B is present. MT 601 Field 53a may be present only if field 34P is present. C21 MT 506 If sequence C is not present, then sequence D is mandatory. If one or more occurrence of sequence C is/are present, then sequence D is optional, swiftnet fin error codes. If sequence C is. Then sequence D is. (once or more) C22 MT 920 If field 12 contains the value '942', at least field 34F Debit/(Debit and Credit) Floor Limit Indicator must be present in the same repetitive sequence. C23 MTs 920 and 942 When only one field 34F is present, subfield 2 must not be used. When both fields 34F are present, subfield 2 of the first 34F must contain D, and subfield 2 of the second 34F must contain C. In MT 920, this applies to each repetitive sequence. C24 MT 940 If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61. MT 942 If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61. Note: This rule does not apply for the field 86 radio s60 error connecting it is the last field in the message. When field 86 is the last field in the message and it is not preceded by a field 61, then it is considered to provide information about the message as a whole, swiftnet fin error codes. 22 July

28 FIN C25 MT n92 Field 79 swiftnet fin error codes a copy of at least any fields of the original message or both must be present. If field 79 is. Then copy of any field(s) of original message is. (that is, minimum one field, any field) Note: SWIFT does not validate the relationship between the copied fields and the original message, hence, any valid field is correct. The system will negatively acknowledge the MT n92 with error code C25 if there is no field after field 11S. C26 MT 430 At least one of the optional fields 32a or 74 must be present. C27 MTs 940, 941, 942, 950, 970, and 972 The first two characters of the three-character currency code in fields 60F, 60M, 62F, swiftnet fin error codes, 62M, 64, 65, 90C, and 90D, in MTs 940, 941, 942, 950, 970 and 972, and field 34F in MT 942 must be the same for all occurrences of these fields. C28 MTs 541, 543, and 578 A value date must only be provided for cash/securities split settlement. That is, in any occurrence of subsequence E3, if value date field :98a::VALU is present, then in sequence E field :22F::STCO//SPST must be present, and settlement amount field :19A::SETT must be present in the same subsequence E3. In any occurrence of subsequence E3 if field :98a::VALU is. Sequence E then field :22F::STCO//SPST (with DSS not present) In the same occurrence of subsequence E3 and field :19A::SETT is. MTs 544, 545, 546, and 547 A value date must only be provided with an effective settlement amount, that is, in any occurrence of subsequence E3, if value date field :98a::VALU is present, then settled amount field :19A::ESTT must be present swiftnet fin error codes the same subsequence. Subsequence E3 If field :98a::VALU is. Then field :19A::ESTT is. Note: MTs 544, swiftnet fin error codes, 545, 546, and 547, see also error code E87, swiftnet fin error codes. MTs 545 and 547, swiftnet fin error codes, see also error code E Error Codes

29 Chapter 3 Alphanumeric Codes MT 586 A value date must only be provided for cash/securities split settlement. That is, in any occurrence of subsequence B5b, if value date field :98a::VALU is present, then in subsequence B5 field :22F::STCO//SPST must be present, and settlement amount field :19A::SETT must be present in the same subsequence B5b, swiftnet fin error codes. In any occurrence of subsequence B5b if field :98a::VALU is. Subsequence B5 then field :22F::STCO//SPST (with DSS not present) is. In the same occurrence of subsequence B5b and field :19A::SETT is. C29 Available. C30 MT 707 At least one of the fields 31E, 32B, 33B, 34B, 39A, 39B, 39C, 44A, 44E, 44F, 44B, 44C, 44D, 79, or 72 must be present. C31 MTs n95 and n96 Either field 79 or a 'copy of any field(s) of the original message to which this message relates', but not both, swiftnet fin error codes, may be present. Note: SWIFT does not validate the relationship between the copied fields and the original message; hence any valid fields are accepted. C32 MTs 300, 303, 304, 305, 306, 320, swiftnet fin error codes, 330, 340, 341, 350, 360, 361, 362, swiftnet fin error codes, 364, 365, 600, 601, 620, and 643 An optional sequence of fields was used. However, a field that is required (that is, indicated by an 'OR') or a field that is mandatory (that is, indicated by ' in.') within this sequence is missing. C33 MTs 768 and 769 If field 71B is present, field 32a must be present. C34 MT 769 Either field 33B or 39C, but not both, must be swiftnet fin error codes. C35 MTs 643, 644, 646, and 649 Either field 21 or 29B must be present. C36 MTs 643 and 646 Subfield 2 (<DATE2>) of field 31F must be present in each occurrence of sequence B. C37 MT 577 Subfield 2 (<DATE2>) of field 67A must not be present. 22 July

30 FIN C38 MT 306 In sequence I, if field 12G contains the code BERM, then field 30T and field 22Y must be present. C39 MT 306 In sequence I, swiftnet fin error codes, if field 12G contains the code AMER, then field 30Y must be present. C40 MT 920 The currency code must be the same for each occurrence of field 34F within vb6 on error goto repetitive sequence. C41 MT 306 The presence of sequence J, subsequence J1, subsequence J2, and field 14B in sequence J depends on the value of field 12F in sequence A, as follows: Sequence Swiftnet fin error codes if field 12F is. Then sequence J is. Then subsequence J1 is. Then subsequence J2 is. Sequence J then field 14B is. AVRF AVRO AVSF AVSO DAVF DAVO Any other value Not applicable Not applicable Not applicable C42 MT 824 The currency code in each of the fields 68A of a sequence of fields 68A preceding a field 19 must be the same, swiftnet fin error codes. C43 MT 646 Either field 32N or 33N must be present. C44 MT 646 If fields 32N and 33N are present in sequence C, field 34a must be present in sequence C. C45 MT 646 If field 23 contains REPRINC or PREPRINC, field 32N must be present in sequence C. C46 MT 646 If field 23 contains INT, field 33N must be present in sequence C. 30 Error Codes

31 Chapter 3 Alphanumeric Codes C47 MT 643 If field 23 contains LOAN/DRAWDOWN or FINARR/DRAWDOWN, sequence B must not be present. C48 MT 643 If field 23 contains LOAN/RENEWAL or FINARR/RENEWAL, sequence B must be present. C49 MT 456 If field 71B is present, the values in fields 32a and 33D must be different, swiftnet fin error codes. C50 MTs 540, 541, 542, and 543 If field :36B: is present in minimum one occurrence of sequence A1, then the type of settlement transaction must be a pair-off or a turn-around, swiftnet fin error codes, that is, sequence E field :22F::SETR//PAIR or :22F::SETR//TURN must be present. 1 if field :36B: is. Sequence E then field :22F::SETR must be. :22F::SETR//PAIR and DSS must not be present or :22F::SETR//TURN and DSS must not be present Not applicable C51 MT 643 If field 23 contains LOAN/DRAWDOWN or LOAN/RENEWAL, field 31R must be present. C52 MT 361 In sequence A, the presence of field 32B depends on field 23A, as follows: If field 23A is. Then field 32B is. CORRBUYER CORRSELLER VOLABUYER VOLASELLER Any other value C53 MT 643 If field 71C is present in any sequence B, field 34a must be present in the same sequence. C54 MT 644 Either field 36 or field 37(A-F) must be present in any sequence B. 22 July

32 FIN C55 MT 644 In any sequence B, the currency code in fields 33B and 34a must be the same. C56 MT 300 In sequence E, the presence of field 22Q depends on field 17Z as follows: Sequence E Swiftnet fin error codes field 17Z is. Then field 22Q is. Y N MTs 305 and 601 In sequence B, the presence of field 22Q depends on field 17Z as follows: Sequence B If field 17Z is. Then field 22Q is. Y N MT 306 In sequence M, the presence of field 22Q depends on field 17Z as follows: Sequence M If field 17Z is. Then field 22Q is. Y N MT 340 In sequence G, the presence of field 22Q depends on field 17Z as follows: Sequence G If field 17Z is., swiftnet fin error codes. Then field 22Q is. Y N MTs 341 and 600 In sequence D, the presence of field 22Q depends on field 17Z as follows: 32 Error Codes

33 Chapter 3 Alphanumeric Codes Sequence D If field 17Z is. Then field 22Q is. Y N MT 360 In sequence O, the presence of field 22Q depends on field 17Z as follows: Sequence Swiftnet fin error codes If field 17Z is. Then field 22Q is., swiftnet fin error codes. Y N MT 361 In sequence P, the presence of field 22Q depends on field 17Z, as follows: Sequence P If field 17Z is. Then field 22Q is. Y N C57 MT 646 If field 34N is present in any sequence B, field 31F in the same sequence B and field 33N in sequence C must be present. C58 MT 300 In field 77D of sequence A, if the code /VALD/ is present, then it must appear in the first 6 characters of the first line and in no other place, and it must be followed by a date expressed as YYYYMMDD and the "end_of_line" separator, that is, ":77D:/VALD/"YYYMMDD"CrLf". See also error code C59, swiftnet fin error codes. MT 304 In field 72 of sequence C, if the code /VALD/ is present, then it must appear in the first 6 characters of the first line and in no other place, and it must be followed by a date expressed as YYYYMMDD and the "end_of_line" separator, that is ":72:/VALD/"YYYMMDD"CrLf". See also error code C59. MT 305 In field 72 of sequence A, if the code /VALD/ is present, then it must appear in the first 6 error c2133 unknown size of the first line and in no other place, and it must be followed by a date expressed as YYYYMMDD and the "end_of_line" separator, that is ":72:/VALD/"YYYYMMDD"CrLf". See also error code C July

34 FIN MT 646 If field 34N is present in any sequence B, the total amount given in field 33N must equal the total amount of all occurrences of field 34N amounts in sequence B. C59 MT 300 In sequence A, if field 77D is present, then: if the first six (6) characters of the first line are equal to /VALD/, then the second line must delphi runtime error 103 present and it must contain "/SETC/" in the first six (6) characters, followed by a valid ISO 4217 currency code and the end of line separator, that is, "/SETC/"<CUR>"CrLf". if the first six (6) characters of the second line are equal to /SETC/, then the first six (6) characters of the first line must be equal to /VALD/. the code "/SETC/" is not allowed in any other place than the first six (6) characters of the second line. if the first six (6) characters of the third line are equal to /SRCE/, then the first six (6) characters of the second line must be equal to "/SETC/". the code "/SRCE/" is not allowed in any other place than the first six (6) characters of the third line. See also error code C58, swiftnet fin error codes. MT 304 In sequence C, if field 72 is present, then: if the first six (6) characters of the second line are equal to /SETC/, then it must be followed by a valid ISO 4217 currency code and the end of line separator, that is, "/SETC/"<CUR>"CrLf". if the first six (6) characters of the second line are equal to /SETC/, then the swiftnet fin error codes six (6) characters of the first line must be equal to "/VALD/". the code "/SETC/" is not allowed in any other place than the first six (6) characters of the second line, swiftnet fin error codes. if the first six (6) characters of the third line are equal to /SRCE/, then the first six (6) characters of the second line must be equal to "/SETC/". the code "/SRCE/" is not allowed in any other place than the first six (6) characters of the third line. See also error code C58. MT 305 In sequence A, if field 72 is present, then: MT 321 if the first six (6) characters of the first line are equal to /VALD/, then the second line must be present and it must contain "/SETC/" in the first six (6) characters, followed by a valid ISO 4217 currency code and the end of line separator, that is, "/SETC/"<CUR>"CrLf". if the first six (6) characters of the second line are equal to /SETC/, then the first six (6) characters of the first line must be equal to "/VALD/". the code "/SETC/" is not system error 79 04 in any other place than the first six (6) characters of the second line. Swiftnet fin error codes sequence B, the presence of field 19A and of the Next Interest Due Date (field :98A::INTR) depends on the Type of Loan/Deposit Event (field :22H::TLDE) in sequence A as follows: 34 Error Codes

35 Chapter 3 Alphanumeric Codes if field :22H::TLDE is. Then field :98A::INTR is. And field :19A::SETT is. Sequence B And field :19A::RODI is. And field :19A::CINT is. And field :19A::NINT is. CONF ROLL MATU MT 800 The amounts in fields 34B and 32A must be the same. C60 MT 307 In sequence A, swiftnet fin error codes, the presence of field :22H::APER and the presence of field :22H::NEGR depends on the field :22H::CRTR as follows: If field :22H::CRTR is. Then field :22H::APER is. And field :22H::NEGR is. ASET AFWD MT 321 In sequence A, the presence of field :99B:: depends on the presence of field :22H::BLOC as follows: If field :22H::BLOC is. Then field :99B:: is. MT halt on error bios In each sequence B, the currency code in fields 32P, 33a and 34a must be the same. C61 MT 307 In sequence A, swiftnet fin error codes, the presence of field :22H::PAFI depends on field :22H::APER as follows: If field :22H::APER is. Then field :22H::PAFI is. OPEF NOPE Field :22H::APER not present MT 321 In sequence B, the presence of field :98A::LDFP depends on the value of field :22H::TLDE in sequence A as follows: 22 July

36 FIN if field :22H::TLDE is. Sequence B then field :98A::LDFP is. MATU Not MATU MT 643 In each sequence C, the currency code in fields db iserror php and 33B must be the same. C62 MT 307 The presence of sequence C depends on field :22H::APER as follows: if field :22H::APER is., swiftnet fin error codes. Then sequence C is. OPEF NOPE Field :22H::APER not present MT 321 In sequence B, the presence of field :99B::DAAC depends on the presence of field :98A::LDFP as follows: Sequence B If field :98A::LDFP is. Then field :99B::DAAC is. C63 MT 307 In sequence A, the presence of the qualifier UNKN in field :22H::NEGR//UNKN depends on the content of field :22H::CRTR, swiftnet fin error codes, of field :22H::APER and of field :22H::PAFI as follows: CRTR//ASET if field :22H:: is. CRTR//AFWD and APER//OPEF CRTR//AFWD and APER//NOPE and PAFI//PAIN CRTR//AFWD and APER//NOPE and PAFI//FINA Then field :22H::NEGR//UNKN is. MT 321 In sequence A, if field 99B is present, then all qualifiers must be present. C64 MT 307 The presence of sequence D depends on the value of field 22H as follows: 36 Error Codes

37 Chapter 3 Alphanumeric Codes If field :22H::CRTR is. And field :22H::APER is. And field :22H::PAFI is. And field :22H::NEGR is. Then sequence D is. ASET Not applicable per error code C60 Not applicable per error code C61 NETC ASET Not applicable per error code C60 Not applicable per error code C61 GRSC ASET Not applicable per error code C60 Not applicable per error code C61 AFWD OPEF Not applicable per error code C61 NETC or GRSC or UNKN AFWD NOPE PAIN NETC or GRSC or UNKN AFWD NOPE FINA NETC AFWD NOPE FINA GRSC C65 MT 567 If the message is a cancellation request status (:23G:CAST), then, in every occurrence of sequence A2 Status, a cancellation processing status must be reported (:25D::CPRC.). If the message is an instruction status (:23G:INST) then, in every occurrence of sequence A2 Status, an instruction processing status (:25D::IPRC.) must be reported, swiftnet fin error codes. If the message is corporate action event processing status (:23G:EVST), then, in every occurrence of sequence A2 Status, an mu wsagetlasterror = wsaewouldblock status (:25D::EPRC.) must be reported. if field 23G is. Then, in every occurrence of sequence A2 field :25D must be. CAST INST EVST :25D::CPRC. :25D::IPRC. :25D::EPRC. C66 MT 643 The number of occurrences of sequence C must be equal to or greater than the number of occurrences of sequence B. C67 MT 516 In sequence A, either field 83C or 87a but not both, may be present. C68 MTs 202 COV and 205 COV In sequence B, if field 56a is present, then field 57a must also be present. 22 July

38 FIN C69 MT 507 In each occurrence of sequence B, if present, if subsequence B1 is present, the presence of subsequences B1a and B1b depends on the value of field :22H::COLL in sequence B as follows: Sequence B (each occurrence) If subsequence B1 is. And field :22H::COLL//Status is., swiftnet fin error codes. Then subsequence B1a is. And subsequence B1b is. CCOL SCOL BCOL (Not applicable see also error code C70) Not applicable Not applicable Not applicable Not applicable Not applicable Note: Error code C70 takes precedence over error code C69. C70 MT 507 In each occurrence of swiftnet fin error codes B, the presence of subsequence B1 depends on the value of fields :25D::COLL//<Status> and :22H::COLL//<Indicator> as follows: Sequence B (each occurrence) If field :25D::COLL/[8c]/4!c Data Source Scheme [8c] is., swiftnet fin error codes. And field :25D::COLL/[8c]/4!c is., swiftnet fin error codes. And field :22H::COLL//4!c is. Then subsequence B1 is. :25D::COLL//ACCT BCOL :25D::COLL//ACCT :25D::COLL//ACCT CCOL SCOL [1] [1] :25D::COLL//REJT Not applicable Not applicable BCOL CCOL [1] SCOL [1] [1] See also error code C69 for additional checks. Error code C70 takes precedence over error code C69. C71 MT 535 In each occurrence of subsequence B1, field :93B::AGGR cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. 38 Error Codes

39 Chapter 3 Alphanumeric Codes Subsequence B1 if field :93B::AGGR is. Repeated Then one occurrence of :93B::AGGR swiftnet fin error codes be. :93B::AGGR//FAMT and DSS must not be present And the other occurrence of :93B::AGGR must be. :93B::AGGR//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 536 In each occurrence of subsequence B1a2, field :36B::PSTA cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B1a2 if field :36B::PSTA is. Then one occurrence of :36B::PSTA must be. And the other occurrence of :36B::PSTA must be. Repeated :36B::PSTA//FAMT :36B::PSTA//AMOR Not repeated Not applicable Not applicable MT 537 In each occurrence of subsequence Error in sound initialization, field :36B::PSTA cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B2b if field :36B::PSTA is. Then one occurrence of :36B::PSTA must be. And the other occurrence of :36B::PSTA must be. Repeated :36B::PSTA//FAMT :36B::PSTA//AMOR Not repeated Not applicable Not applicable MTs 540, 541, 542, and 543 In sequence C, field :36B::SETT cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence C if field :36B::SETT is. Then one occurrence of :36B::SETT must be. And the swiftnet fin error codes occurrence of :36B::SETT must be. Repeated :36B::SETT//FAMT :36B::SETT//AMOR Not repeated Not applicable Not applicable MTs 544, 545, 546, and 547 In sequence C, field :36B::ESTT cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence C if field :36B::SETT is. Then one occurrence of :36B::ESTT must be. And the other occurrence of :36B::ESTT must be. Repeated :36B::ESTT//FAMT :36B::ESTT//AMOR Not repeated Not applicable Not applicable MT 548 In sequence. B, field :36B::SETT cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. 22 July

40 FIN Sequence B if field :36B::SETT is. Then one occurrence of :36B::SETT must be. And the other occurrence of :36B::SETT must be. Repeated :36B::SETT//FAMT :36B::SETT//AMOR Not repeated Not applicable Not applicable MT 564 In each occurrence of subsequence B2, field :93B::ELIG cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B2 if field :93B::ELIG is. Repeated Then one atm er rak error ost of :93B::ELIG must be. :93B::ELIG//FAMT and DSS must not be present And the other occurrence of :93B::ELIG must be. error 021 symbol already defined lvlexp and DSS must not be present Not repeated Not applicable Not applicable MT 565 In subsequence B2, field :93B::ELIG cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B2 if field :93B::ELIG is. Repeated Then one occurrence of :93B::ELIG must be., swiftnet fin error codes. :93B::ELIG//FAMT and DSS must not be present And the other occurrence of :93B::ELIG must be. :93B::ELIG//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 566 In sequence B, field :93B::ELIG cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Direct3d device initialization error Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence B if field :93B::ELIG is. Repeated Then one occurrence of :93B::ELIG must be. :93B::ELIG//FAMT and DSS must not be present And the other occurrence of :93B::ELIG must be. :93B::ELIG//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 567 In sequence B, field :36B::STAQ cannot appear more than twice (maximum 2 occurrences). When repeated, swiftnet fin error codes, one occurrence must have Quantity Type Swiftnet fin error codes FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence B if field :36B::STAQ. Then one occurrence of :36B::STAQ must be. And the other occurrence of :36B::STAQ must be. Repeated :36B::STAQ//FAMT :36B::STAQ//AMOR Not repeated Not applicable Not applicable 40 Error Codes

View more

USER HANDBOOK TRANSLATION

Russian National Association SWIFT prepared Russian translation of the SWIFT User Handbook of November 2019, which includes following books:

Corporate and legal

Glossary
Corporate rules
SWIFT by-laws
General terms and conditions SWIFT
Personal data protection policy
Price-list for Messaging and Solutions
Pricing and invoicing
BIC Policy

Services Description

MA-CUG. For corporates
SCORE 2.6. For corporates
Cash reporting 5.0. Swiftnet fin error codes description

Exceptions and Investigations (E&I) version 1.2:

Service Description
Bank-bank. Message Reference Guide
Integration Guide
Bulk Payments 2.1
BICPlusIBAN Directory
BIC Enquiry Tool 3.0

SWIFTNet FIN

FIN Error Codes
FIN Service Description
FIN System Messages
Standards MT Usage Guidelines
Standards. General Information

Standards:

Category 1 - Customer Payments and Cheques
Category 2 - Financial Institution Transfers
Category 3 - Treasury Markets – Foreign Exchange, Money Markets and Derivatives. Volume 1 (MT 300 – MT 341)
Category 3 - Treasury Markets – Foreign Usr/sbin/smbldap-groupadd error adding group, Money Markets and Derivatives. Volume 2 (MT 350 – MT swiftnet fin error codes 4 – Collection and Cash Letters
Category 5 – Securities Markets. Volume 1 (MT 500 – 518)
Category 5 – Securities Markets. Volume 2 (MT 519-543)
Category 5 – Securities Markets. Volume 3 (MT 544-567)
Category 5 – Securities Markets. Volume 4 (MT 568-599)
Category 6 – Treasury Markets - Commodities
Category 7 – Documentary Credits and Guarantees
Category 8 – Travelers Cheques
Category 9 – Cash Management and Customer Status
Category n – Common Group Messages

Recommendations:

SWIFT-RUR
SWIFT-RUS
ISO 20022.RU

swiftnet fin error codes

Swiftnet fin error codes - not understand

USER HANDBOOK TRANSLATION

Russian National Association SWIFT prepared Russian translation of the SWIFT User Handbook of November 2019, which includes following books:

Corporate and legal

Glossary
Corporate rules
SWIFT by-laws
General terms and conditions SWIFT
Personal data protection policy
Price-list for Messaging and Solutions
Pricing and invoicing
BIC Policy

Services Description

MA-CUG. For corporates
SCORE 2.6. For corporates
Cash reporting 5.0. Service description

Exceptions and Investigations (E&I) version 1.2:

Service Description
Bank-bank. Message Reference Guide
Integration Guide
Bulk Payments 2.1
BICPlusIBAN Directory
BIC Enquiry Tool 3.0

SWIFTNet FIN

FIN Error Codes
FIN Service Description
FIN System Messages
Standards MT Usage Guidelines
Standards. General Information

Standards:

Category 1 - Customer Payments and Cheques
Category 2 - Financial Institution Transfers
Category 3 - Treasury Markets – Foreign Exchange, Money Markets and Derivatives. Volume 1 (MT 300 – MT 341)
Category 3 - Treasury Markets – Foreign Exchange, Money Markets and Derivatives. Volume 2 (MT 350 – MT 399)
Category 4 – Collection and Cash Letters
Category 5 – Securities Markets. Volume 1 (MT 500 – 518)
Category 5 – Securities Markets. Volume 2 (MT 519-543)
Category 5 – Securities Markets. Volume 3 (MT 544-567)
Category 5 – Securities Markets. Volume 4 (MT 568-599)
Category 6 – Treasury Markets - Commodities
Category 7 – Documentary Credits and Guarantees
Category 8 – Travelers Cheques
Category 9 – Cash Management and Customer Status
Category n – Common Group Messages

Recommendations:

SWIFT-RUR
SWIFT-RUS
ISO 20022.RU

Forging SWIFT MT Payment Messages for fun and pr... research!

TLDR: With a bit of research and support we were able to demonstrate a proof of concept for introducing a fraudulent payment message to move £0.5M from one account to another, by manually forging a raw SWIFT MT103 message, and leveraging specific system trust relationships to do the hard work for us!

Before we begin: This research is based on work we performed in close-collaboration with one of our clients; however, the systems, architecture, and payment-related details have been generalized / redacted / modified as to not disclose information specific to their environment.

With that said... *clears throat*

The typical Tactics, Techniques and Procedures (TTPs) against SWIFT systems we see in reports and the media are - for the most part - the following:

  1. Compromise the institution's network;
  2. Move laterally towards critical payment systems;
  3. Compromise multiple SWIFT Payment Operator (PO) credentials;
  4. Access the institution's SWIFT Messaging Interface (MI);
  5. Keys in - and then authorize - payment messages using the compromised PO accounts on the MI.

This attack-path requires the compromise of multiple users, multiple systems, an understanding of how to use the target application, bypass of 2FA, attempts to hide access logs, avoid alerting the legitimate operators, attempts to disrupt physical evidence, bespoke malware, etc. – so, quite involved and difficult. Now that’s all good and fine, but having reviewed a few different payment system architectures over the years, I can’t help but wonder:

“Can't an attacker just target the system at a lower level? Why not target the Message Queues directly? Can it be done?”

Well, let's find out! My mission begins!

So, first things first! I needed to fully understand the specific “section” of the target institution's payment landscape I was going to focus on for this research. In this narrative, there will be a system called “Payment System” (SYS). This system is part of the institution's back-office payment landscape, receiving data in a custom format and output's an initial payment instructions in ISO 15022 / RJE / SWIFT MT format.  The reason I sought this scenario was specifically because I wanted to focus on attempting to forge an MT103 payment message - that is:

  • MT – “Message Type” Literal;
  • 1 – Category 1 (Customer Payments and Cheques);
  • 0 – Group 0 (Financial Institution Transfer);
  • 3 – Type 3 (Notification);
  • All together this is classified as the MT103 “Single Customer Credit Transfer”.

Message type aside, what does this payment flow look like at a high level? Well I’ve only gone and made a fancy diagram for this!

SWIFT Architecture 01 Dark2

Overall this is a very typical and generic architecture design. However, let me roughly break down what this does:

  1. The Payment System (SYS) ingests data in a custom - or alternative - message format from it's respective upstream systems. SYS then outputs an initial payment instruction in SWIFT MT format;
  2. SYS sends this initial message downstream to a shared middelware (MID) component, which converts (if necessary) the received message into the modern MT format understood by SWIFT - Essentially a message broker used by a range of upstream payment systems within the institution;
  3. MID forwards the message in it's new format on to the institution's Messaging Interface (let's say its SAA in this instance) for processing;
  4. Once received by SAA, the message content is read by the institution's sanction screening / Anti-money laundering systems (SANCT).
  5. Given no issues are found, the message is sent on to the institution's Communication Interface (SWIFT Alliance Gateway), where it's then signed and routed to the recipient institution over SWIFTNet.

OK, so now I have a general understanding of what I'm up against. But if I wanted to exploit the relationships between these systems to introduce a  fraudulent payment without targeting any payment operators, I was going to need to dig deeper and understand the fundamental technologies in use!

So how are these messages actually "passed" between each system? I need to know exactly what this looks like and how its done!

More often than not, Message Queues (MQ) are heavily used to pass messages between components in a large payment system. However, there are also various “Adapter” that may be used between systems communicating directly with the SAG (Such as SAA or other bespoke/3rd party systems). These are typically the:

  • Remote API Host Adapter (RAHA);
  • MQ Host Adapter (MQHA);
  • Web Services Host Adapter (WSHA).

Having identified that MQ was in use, my initial assumption was that there was most likely a dedicated Queue Manager (QM) server somewhere hosting various queues that systems push and pull messages from? However, due to SWIFT CSP requirements, this would most likely - at a minimum - take the form of two Queue Managers. One which manages the queues within the SWIFT Secure Zone, and another that manages queues for the general corporate network and back office systems.

Let's update that diagram to track / represent this understanding:

SWIFT Architecture 02 Dark4

Now I could research how this "messaging" worked!

There are multiple ways to configure Message Queues architectures, in this case there were various dedicated input and output queues for each system, and the message flow looks something like this:

SWIFT MQ 01 Dark2

Full disclosure, turns out it’s hard to draw an accurate - yet simple - MQ flow diagram (that one was basically my 4th attempt). So it’s... accurate "enough" for what we needed to remember!

Now I had a good understanding of how it all worked, it is time to define my goal: "Place a payment message directly on to a queue, and have it successfully processed by all downstream systems".

This sounds simple, just write a message to a queue, right? But there are a few complications!

  1. Why are there few indications of this attack vector in the wild?
  2. How do I even gain “write” access to the right queue?
  3. What protects the message on the queues?
  4. What protects the messages in transit?
  5. What format are the messages in?
  6. What is the correct syntax for that message format at any particular queue (0 margin for error)?
  7. Where does PKI come in? How / where / when are the messages signed?
  8. Can I somehow get around the message signing?
  9. What values in the messages are dependent / controlled / defined by the system processing them (out of my control)?
  10. What is the maximum amount I can transfer using Straight Through Processing, without alerting the institution / requiring manual validation?

But OK, there's no point dwelling on all of that right now, I'll just clearly define what I want to do!

The goal:

  1. Successfully write a payment instruction for 500,000 GBP;
  2. Inject that message directly onto a specific queue;
  3. Have the message pass environment-specific validation rules;
  4. Have the message pass sanctions and AML checks.
  5. Have the message successfully signed;
  6. Have the message pass SWIFTNet-specific validation rules;

What I was not interested in doing for this research - yet needed to understand nevertheless for a full attack chain was:

  1. How to compromise the institution's network;
  2. How to gain access to the MQ admin's workstation;
  3. How to obtain the pre-requisite credentials.

What I wanted to 100% avoid at all costs:

  1. The attack involving SWIFT payment operators in any way;
  2. The attack involving SWIFT application access in any way;
  3. A need to compromise signing keys / HSMs;
  4. A need to compromise SWIFTNet operator accounts or certificates or any type of PKI;.

Now I had an idea of what to do, I needed to make sure I could write a raw MT103 payment instruction! Typically, even when operators write payment messages using a messaging interface application like Alliance Access, they only really write the message “body” via a nice GUI. As raw data this could look something like:

:20:TRANSACTIONRF103
:23B:CRED
:32A:200102GBP500000,00
:33B:GBP500000,00
:50K:/GB22EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59K:/FR20FBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, PARIS, FR
:70:12345-67890
:71A:SHA

I'll break this down in the following table:

NameFieldValue
Transaction Reference20TRANSACTIONRF103
Bank Operation Code23BCRED (Message is to "credit" some beneficiary)
Value Date / Currency / Amount32A200102 (02/01/2020) GBP 500,000.00
Currency / Original Credit Amount33BGBP 500000,00 (£500,000.00)
Ordering Customer50KGB22EBNK88227712345678 (IBAN)
JOHN DOE (Name)
JOHN'S BUSINESS LTD (Line 1)
21 JOHN STREET, LONDON, GB (Line 2)
Beneficiary59KFR20FBNK88332287654321 (IBAN)
ALICE SMITH (Name)
ALICE'S COMPANY (Line 1)
10 ALICE STREET, PARIS, FR (Line 2)
Remittance Information7012345-67890 (essentially a payment reference)
Details of Charge71ASHA (Shared charge between sender and receiver)

Now as this is a valid message body, if I were targeting a payment operator on SWIFT Alliance Access, I could - for the "most" part - simply paste the message into SAA's raw message creation interface and I'd be pretty much done. With the exception of adding the sender / recipient BIC codes and most likely selecting a business unit. However, these values are not stored in the message body.  

Not stored in the message body you say? Well that complicates things! Where are they stored exactly?

The message “body” is referred to as “block 4” (aka the “Text Block”) within the SWIFT MT standard. As suggested by the name, there is probably also a block 1-3. This is correct; and these blocks are typically generated by the payment processing applications - such as SWIFT Alliance Access - and not necessarily input by the operators. A "complete" MT103 message consists of 6 blocks:

  • Block 1 – Basic Header
  • Block 2 – Application Header
  • Block 3 – User Header
  • Block 4 – Text Block
  • Block 5 – Trailer
  • Block 6 – System block

So it looked like I was going to need to learn how to craft these various “blocks” from scratch.

Block 1 (Basic header)

Reading through some documentation, I crafted the following “Basic header” block:

{1:F01EBNKGB20AXXX0000999999}

A breakdown of what this translates too is as follows:

NameValueContext
Basic Header Flag1Block 1 (Not 2, 3, 4, or 5)
Application TypeFFIN Application
Message Type0101 = FIN (I.e not ACK/NACK)
Sender BICEBNKGB20EBNK (Bank Code) GB (Country Code) 20 (Location Code)
Sender Logical TerminalATypically A, unless they are a significantly large institution and require multiple terminals
Sender BranchXXXAll X if no branch needed
Session Number0000The session number for the message
Sequence Number 999999The sequence number of the message

Taking a step back, I already identified two potential problems: the “session” and “sequence” numbers! These are described as follows:

  • Session Number – Must also equal the current application session number of the application entity that receives the input message.
  • Sequence number – The sequence number must be equal to the next expected number.

Hmmm, at this point I was not sure how I could predetermine a valid session and/or sequence number - considering they seemed to be application and "traffic" specific? But there was nothing I could do at the time, so I noted it down in a list of "issues/blockers" to come back to later.

Block 2 (Application Header)

A bit more dry reading later, I managed to also throw together an application header:

{2:I103FBNKFR20XXXXN}

Again, I’ve broken this down so it makes sense (if it didn’t already; I’m not one to assume):

NameValueContext
Application Header Flag2Block 2
I/O IdentifierIInput Message (a message being sent)
Message Type103103 = Single Customer Credit Transaction
Recipient BICFBNKFR20FBNK (Bank Code) FR (Country Code) 20 (Location Code)
Recipient Logical TerminalXAll General Purpose Application Messages must use "X"
Recipient BranchXXXAll General Purpose Application Messages must use "XXX"
Message PriorityNNormal (Not Urgent)

Awesome! No issues crafting this header!

Note: At this point I should probably mention that these BIC codes are not "real", however are accurate in terms of in format and length.

Block 3 (User Header)

The third block is called the “User Header” block, which can be used to define some “special” processing rules. By leverage this header, I could specify that the message should be processed using “Straight Through Processing” (STP) rules which essentially attempts to ensure that the message is processed end-to-end without human intervention. This could be specified as follows:

{3:{119:STP}}

However, this was not yet a valid header! As of November 2018 the user header requires a mandatory “Unique end-to-end transaction reference” (UETR) value, which was introduced as part of SWIFT's Global Payments Innovation initiative (gpi)!

This is a Globally Unique Identifier (GUID) compliant with the 4th version of the generation algorithm used by the IETF standard "RFC4122". This consists of 32 hexadecimal characters, divided into 5 parts by hyphens as follows:

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

where:

  • x – any lowercase hexadecimal character;
  • 4 – fixed value;
  • y – either: 8, 9, a, b.

This value can be generated using Python as seen below:

$ python -c 'import uuid; id = uuid.uuid4(); print "Value:", id; print "Version:", id.version, id.variant'
Value: 8b1b42b5-669f-46ff-b2f2-c21f99788834
Version: 4 specified in RFC 4122

With an acceptable UETR generated, this is how the third block looked:

{3:{119:STP}{121:8b1b42b5-669f-46ff-b2f2-c21f99788834}}

And as before, a breakdown can be found below:

NameValueContext
User Header Flag3Block 3
Validation Flag119Indicates whether FIN must perform any type of special validation
Validation FieldSTPRequests the FIN system to validate the message according to the straight through processing principles
UETR Field121Indicates the Unique end-to-end transaction reference value
UETR Value8b1b42b5-669f-46ff-b2f2-c21f99788834Unique end-to-end transaction reference used to track payment instruction

Block 5 and 6 (Trailer and System Blocks)

I’ve already discussed “block 4” (the message body), so to wrap this section up, I'll be looking at the final 2 blocks: Block 5, aka the “Trailer”; and block S, aka the “System” block.

Before going forward, let me take a moment to explain the pointlessly complicated concept of input and output messages:

  • An “input” message (I) is a message which is traveling “outbound” from the institution. So this is a message being “input” by an operator and sent by the institution to another institution.
  • An “output” message (O) is a message which is traveling “inbound” to the institution. So this is a message being “output” by SWIFTNet and being received by the institution.

OK, moving swiftly (aaaahhhhh!) on.

For Input messages, these blocks were not too much of a problem. The headers only really seemed to be used to flag whether the message was for training / testing or to flag if it was a possible duplicate, which syntactically took the following form:

{5:{TNG:}}{S:{SPD:}}

Where “TNG” indicated “training” and “SPD” indicated “possible duplicate”.

However, with Output messages, it got considerably more complicated. An example of what the trailer and system block could look like on an Output message is the following:

{5:{MAC:13461AEF}{CHK:4A3367FD3D76}{TNG:}}{S:{SPD:}{SAC:}{COP:P}
{MDG:5E87F8F390E5FB886E8311E4D7C994371FA9AF3119B2C314DAE458738AFF08AC}}

A breakdown of these various values is:

Trailer ({5:)
MAC – Message Authentication Code calculated based on the entire contents of the message using a key that has been exchanged with the destination bank and a secret algorithm;
CHK – This is a PKI checksum of the message body, used to ensure the message has not been corrupted in transit;
TNG – A flag to indicate that the message is a Testing and Training Message.

System ({S:)
SPD – Possible Duplicate Flag
SAC – Successfully Authenticated and Authorized Flag. This is only present if:

  1. Signature verification was successful.
  2. RMA (Relationship Management Application) authorization and verification was successful.

COP – Flag indicating that this is the primary message copy;
MDG – The HMAC256 of the message using LAU keys.

However, these seemed to only be values I would need to consider if I was to try and forge an “incoming” message from SWIFTNet or an "outbound" message on the output of the SAG.

So... I'll stick with crafting an “input" message trailer:

{5:{TNG:}}{S:{SPD:}}

Now, having said all that, it turned out the trailer block did seem to sometimes hold a MAC code and a message checksum (sigh), meaning I actually needed to construct something like:

{5:{MAC:XXXXXXXX}{CHK:XXXXXXXXXXXX}{TNG:}}{S:{SPD:}}

So that was +2 to my "issues/blockers" list. However, issues aside, I now understood the complete message format, and could put it all together and save the following as a draft / template MT103 message:

{1:F01EBNKGB20AXXX8888999999}
{2:I103FBNKFR20XXXXN}
{3:{119:STP}{121:8b1b42b5-669f-46ff-b2f2-c21f99788834}}
{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200102GBP500000,00
:33B:GBP500000,00
:50K:/GB22EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/FR20FBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, PARIS, FR
:70:12345-67890
:71A:SHA
-}
{5:{MAC:XXXXXXXX}{CHK:YYYYYYYYYYYY}{TNG:}}{S:{SPD:}}

Highlighted in bold above are the areas of the message I was - at this point - unable to pre-determine. Nevertheless, a summary of what that the message describes is:

  • Using the transaction reference “TRANSACTIONRF103”;
  • please transfer 500,000.00 GBP;
  • from John Doe, (IBAN: GB22EBNK88227712345678) at “English Bank” (BIC: EBNKGB20);
  • to Alice Smith (IBAN: FR20FBNK88332287654321) at “French Bank” (BIC: FBNKFR20);
  • Furthermore, please ensure the transaction charge is shared between the two institutions;
  • and mark the payment with a reference of “12345-67890”.

To wrap up this section, i wanted to take a moment to explain some logic behind the target of 500,000 GBP, as it is also important.

Aside from the many reasons it would be better to transfer [even] smaller amounts (which is an increasingly common tactic deployed by modern threat actors), why not go higher? This is where it’s important to understand the system and environment you are targeting.

In this instance, let's assume that by doing recon for a while I gathered the understanding that:

  • If a message comes from SYS which is over £500k;
  • even if it has been subject to a 4 eye check;
  • and even if it is flagged for STP processing;
  • route it to a verification queue and hold it for manual verification.

This was because a transaction over £500k was determined to be “abnormal” for SYS. As such, if my transaction was greater, the message would not propagate through all systems automatically.

OK, so now that I understood:

  • how the system worked;
  • how it communicated;
  • the fundamental structure of a raw MT103 payment messages;
  • and how much I could reliably [attempt] to transfer.

And with that, it was time to take a break from MT standards and establish an understanding of how I would even get into a position to put this into practice!

To place a message on a queue, I was going to need two things:

  • Access to the correct queue manager;
  • Write access to the correct queues.

Depending on the environment and organisation, access to queue managers could be quite different and complex. However a bare-bones setup may take the following form:

  • An MQ Administrator accesses their dedicated workstation using AD credentials;
  • They then remotely access a dedicated jump server via RDP which only their host is whitelisted to access;
  • This may be required as the queues may make use of Channel Authentication Records, authorizing specific systems and user accounts access to specific queues;
  • The channels may further be protected by MQ Message Encryption (MQME) which encrypts messages at rest based on specific channels. As such, even if someone was a “super duper master admin” they would only be able to read / write to queues specifically allocated to them within the MQME configuration file (potential target for another time?);
  • The MQ Admin can then use tools such via the Jump Server to read/write to their desired message queues.

So, in this scenario, to gain access to the message queues I - as an attacker - would need to compromise the MQ admin’s AD account and workstations, then use this to gain access to the jump host, from where I could then access the message queues given I knew the correct channel name and was configured with authorization to access it... and maybe throw some MFA in there...

That is understandably a significant requirement! However, when discussion sophisticated attacks against Financial Market Infrastructure (FMI), it is more than reasonable to accept that an Advanced Persistent Threat (APT) would see this as a feasible objective - We don't need to dig into the history of how sophisticated attacks targeting SWIFT systems can be.

Next, it was time to finally identify a feasible attack vector for message forgery.

Now with an idea of how to gain the right access, as well as an understanding of the various technologies and security controls in place; I update my diagram:

SWIFT Security Dark2

You may have noticed I've added something called “LAU” around the SAA-to-SAG adapter, and another “LAU” to the MID-to-SAA MQ channels, which I have yet to explain.  “Local Authentication” (LAU) is a security control implemented by SWIFT to authenticate messages using a pair of shared keys between two systems. These keys are combined and used to generate a SHA256 HMAC of the message and append it to the S block. This can then be validated by the recipient system. Effectively, this validates the origin and authenticity of a message. As such, even if an attacker was in position to introduce a fraudulent payment, they'd first need to compromise both the left and the right LAU signing keys, generate the correct HMAC, and append it to the message in order to have it accepted / processed successfully.

But LAU aside, I now just needed to figure out which queue to target! There were a lot of queues to work with as each system essentially has multiple “input” and “output” queues. With that in mind, it was important to note that: an incoming message would require being in the format expected by the target system (from a specific upstream system) and an outgoing message would need to be in the format “produced” by one target system and “expected / ingested / processed” by its respective downstream system. So to figure this out, I worked backwards from the Gateway.

Targeting SAG

This was the least feasible attack vector!

  1. I hadn't really looked into how the SWIFT adapters worked - If only I could research literally everything);
  2. SAA and SAG implemented LAU on messages sent between them - An excellent security control!;
  3. The output of SAG was directly on to SWIFTNet which would entail all sorts of other complications - this is an understatement)!

Next!

Targeting SAA

So what if I wanted to drop a message on the “outbound” channel of SAA?

LAU and the SWIFT adapter aside, remember those session and sequence numbers? Well, messages which leave SAA are in the near-final stages of their outbound life-cycle, and as far as I understood would need to have valid session and sequence values. Given I didn't know how to generate these values without gaining access to SAA or how they worked in general (and lets not forget the LAU signing) this didn't currently seem feasible.

Next!

Targeting SANCT

This solution didn't actually transport messages back and forth; it just reads messages off the queues and performed checks on their details. Not much I could wanted to leverage here.

Targeting MID

To target MID, I could try and inject a message onto SAA’s “input” queue, or the “output” queue of MID. This would only need to match the format of messages produced by the Middleware solution (MID). Following this, in theory, the [mistial] message session and sequence number would be added by SAA, along with the UETR. This was promising!

However, MID was a SWIFT “message partner”, which are typically solutions developed using the Alliance Access Development Kit that allows vendors to develop SWIFTNet compatible software, and consequentially, implement LAU. So again, in-order to forge a message here, I’d need to compromise the left and right LAU signing keys used between SAA and MID, manually HMAC the message (correctly!), and then place it on the correct queue... This also no longer looked promising...

Targeting SYS

OK, how about the input of the next system down - the "Payment System"?

As described previously, the inbound data was a custom “application specific” payment instruction from the institutions back office systems, and not a SWIFT MT message. This would be an entirely new core concept I'd need to reverse - not ideal for this project.

But how about the output queue?

Although SYS received custom format data, I found that it output what seemed to be an initial SWIFT MT messages. This was perfect! Additionally, SYS did not have LAU between itself and MID because (unlike MID) SYS was not a SWIFT message partner, and was just one of many-many systems within the institution that formed their overall payment landscape.

Additionally, because SYS was esentially just one small piece of a much larger back office architecture, it was not part of the SWIFT Secure Zone (after all you cant have your entire estate in the Secure Zone - that defeats the purpose) and as such, made use of the Queue Manager within a more accessible section of the general corporate environment (QM1).

With this in mind, and having - in theory - compromised the MQ admin, I could leverage their access to access on the corporate network to authenticate to QM1. I could - in theory -  then write a fraudulent payment message to the SYS “output” queue, which we will call “SYS_PAY_OUT_Q” from here on.

OK! It seems like I finally had an idea of what to do! But before I could put it into practice, I of course needed to create a diagram of the attack:

SWIFT Attack Dark2

I think it’s important to take a minute to refer back to the concept of “trust” which is what lead to this attack diagram. My theory behind why this may work is because the MID application, implicitly trusts whatever it receives from its respective upstream systems. This is intentional, as by design the security model of the payment landscape ensures that: at any point a message can be created, a 4 (or 6) eye check is performed. If there was a system whose purpose it was to ensure the validity of a payment message at any point upstream, the downstream systems should have no real issue processing that message (with some exceptions). After all, It would be next to-impossible to maintain a high-throughput payment system without this design.

And with that said, the plan was now clear:

  • Leverage the access of a Message Queue administrator;
  • to abuse the “trust relationship” between SYS, MID, and SAA;
  • to introduce a fraudulent payment message directly on to the output queue of SYS;
  • by leaning on my new found understanding of complete MT103 payment messages.

It was finally time to try to demonstrate a Proof-of-Concept attack!

So at this point I believe I had everything I needed in order to execute the attack:

  • The target system!
  • The message format!
  • The queue manager!
  • The queue!
  • The access requirements!
  • The generously granted access to a fully functional SWIFT messaging architecture! (that’s a good one to have!)
  • The extra-generously granted support of various SMEs from the target institution! (This was even better to have!)

Message Forgery

I needed to begin by creating a valid payment message using valid details from the target institution. So before moving on I was provided with the following (Note: as with many things in this post, these details have been faked):

  • Debtor Account Details – John Doe, GB12EBNK88227712345678 at EBNKGB20
  • Creditor Account Details – Alice Smith, GB15EBNK88332287654321 at EBNKGB20

Some of you may have notice that the sending and receiving BIC’s are the same. This was because, for the sake of the research, I wanted to send the message back to the target institution via SWIFTNet so that I could analyse its full end-to-end message history. Furthermore, you may have noticed we are using "test & training" BIC code (where the 8th character is a 0) - this was to make sure, you know, that I kept my job.

But yes, with access to these "valid" account details and the knowledge gained during the research so far, I could now forge a complete Input MT103 messages:

{1:F01EBNKGB20AXXX0000000000}
{2:I103EBNKGB20XXXXN}
{3:{119:STP}{121:eb02c40e-e060-400a-ac74-47f076dd26e3}}
{4:
:20:TRANSACTIONREF103
:23B:CRED
:32A:200103GBP500000
:33B:GBP500000
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}{5:{TNG:}}{S:{SPD:}}

Note: Field 33B is actually an optional field, however, the MT standard stated that “If the country codes of both the Sender’s and the Receiver’s BIC belong to the country code list, then field 33B is mandatory”. As such, if 33B was not present in the message, it would fail network validation rules and SWIFTNet would return a NAK with the error code: D49.

Optional / Mandatory fields aside, it was not quite that simple! There were a few minor changes I needed to make based on the specific point in the message's its life-cycle I was planning to introduce it!

As I list these changes, remember that the objective is to introduce the message to the output queue of SYS (Which exists before MID, SAA and SAG)

  1. The first 3 blocks needed to be placed on a single line;
  2. Remove field 121 (UETR) from the User Header, as this would be generated by SAA during processing;
  3. Remove 1 character from the transaction reference as it needed to be exactly 16 characters (classic user error);
  4. Add decimal point to transaction amount using a comma - otherwise it would fail syntax validation rules;
  5. Ensure the IBAN's were real and accurate, otherwise it seemed the message would fail some type of signature validation on the SWIFT network. The IBANs are fake here, but during the real PoC we used accurate account details in collaboration with the target institution;
  6. Remove the trailer block (5) - as this would be appended by SAA during processing;
  7. Remove the System Block (S) - as this would be completed by the SAG.

And the final message was as follows:

{1:F01EBNKGB20AXXX8888999999}{2:I103EBNKGB20XXXXN}{3:{119:STP}}{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200103GBP500000,00
:33B:GBP500000,00
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}

Note that the location in which I introduce the message has resolved all of the "issues / blockers" I'd tracked whilst researching the message structure! It would seem the further upstream you go, the easier the attack becomes - given MQ is still used as a transport medium.

Message Injection

Now I had my raw MT103 message, I just need to save it to a file (“Message.txt” - sure why not) and place onto the “SYS_PAY_OUT_Q” queue using one of the admin's tools:

  1. With access to a sole MQ Administrator's AD account;
  2. We connect to the MQ admins machine;
  3. Log into the Jump Server;
  4. Open our MQ tools of choice and authenticate to queue manager (QM1) where the output queue for SYS was managed;
  5. Connected to the "SYS_PAY_OUT_Q" queue;
  6. Selected my forged “Message.txt” file;
  7. Invoked the “write to queue” function;

And it was off!

Loggin in to Alliance Access and opening the message history tab, we sat awaiting for an update. Waiting, waiting, waiting… waiting… and...

ACK! It worked!

That's a joke; did we hell receive an ACK!

See, this last section is written slightly more "linear" than what actually happened. Remember those "tweaks" used to fix the message in the previous section? I hadn't quite figured that out yet...

So roughly seven NACKs later - each time troubleshooting and then fixing a different issues - we did indeed, see an ACK! The message was successfully processed by all systems, passed target system validation rules, passed sanctions and AML screening, passed SWIFTNet validation rules, and SWIFT’s regional processor had received the message and sent an "Acknowledgement of receipt" response to the sending institution!

For the sake of completeness, I’ve included the ACK below:

{1:F21EBNKGB20AXXX1947392344}{4:{177:2001031102}{451:0}}

And of course a breakdown of what it all means:

NameValueContext
Basic Header Flag1Block 1
Application TypeFF = FIN Application
Message Type2121 = ACK
Institution CodeEBNKGB20AXXXEBNKGB20 (BIC) A (Logical Terminal) XXX (Branch)
Sequence and Session No.19473923441947 (Sequence No.) 392344 (Session No.)
Date Tag177200103 (Date) 1102 (Time)
Accept / Reject Tag4510 = Accepted by SWIFTNet

Excellent! WooHoo! It worked! ... That took a lot of time and effort!

Closer Inspection

But the ACK wasn't enough, I wanted to make sure I understood what had happened to the message throughout its life-cycle. From the message I placed on the initial queue, to being processed by SWIFTNet.

Thankfully, as we sent the message back to the target institution we could see its entire message history. I already knew what the raw message placed on the queue looked like, so I wanted to focus on what became of the message once it had been processed by SAA:

{1:F01EBNKGB20AXXX8888999999}{2:I103EBNKGB20XXXXN}{3:{119:STP}{121:b42857ce-3931-49bf-ba34-16dd7a0c929f}}{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200103GBP500000,00
:33B:GBP500000,00
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}
{5:{TNG:}}{S:{SPD:}}
  • The end-to-end tracking UUID had been generated and added (b42857ce-3931-49bf-ba34-16dd7a0c929f) in block 3;
  • The message trailer had been added ({5:{TNG:}}) where I could see that - due to the BIC code used - SAA had flagged the message as "test and training".
  • Additionally, an initial System Block segment had been added ({S:{SPD:}}), tagging the message as a possible duplicate. I wonder why - *cough* 7th attempt *cough*?

OK, so that was SAA. Now let’s see how it looked it once it passed through the Gateway and regional processor:

{1:F01EBNKGB20AXXX1947392344}{2:O1031102200103EBNKGB20AXXX19473923442001031104N}{3:{119:STP}{121:b42857ce-3931-49bf-ba34-16dd7a0c929f}}{4:
:20:TRANSACTIONRF103
:23B:CRED
:32A:200103GBP500000
:33B:GBP500000
:50K:/GB21EBNK88227712345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59:/GB22EBNK88332287654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MANCHESTER, GB
:70:FORGED-PAYMENT-TEST
:71A:SHA
-}
{5:{MAC:13579112}{CHK:D8E8FCA2DC0F}{TNG:}}{S:{SPD:}{SAC:}{COP:P}}

OK, we can see a few changes now.

  • The session and sequence numbers have been populated (1947392344);
  • The I/O identifier in block 2 has been updated to track that it is now an "Output" message;
  • The additional data within Block 2 is a combination of the input time, date, BIC, session and sequence numbers, output date/time, and priority;
  • The trailer has been updated with a message authentication code (MAC) calculated based on the entire contents of the message using a pre-shared key and a secret algorithm;
  • Additionally, a checksum of the message body has been stored within the trailer’s “CHK” tag. This is used by the network to ensure message integrity.

I also took a look at the entire outbound message history, just to see all the “Success” and “No violation” statements to make it feel even more awesome!

So that's that really...

With a bit of research and support I was able to demonstrate a PoC for introducing a fraudulent payment message to move funds from one account to another, by manually forging a raw SWIFT MT103 single customer credit transfer message, and leveraging various system trust relationships to do a lot of the hard work for me!

As mentioned briefly in the introduction, this is not something I have really seen or heard of happening in practice or in the "wild". Perhaps because it clearly takes a lot of work... and there is a huge margin for error. However, if an adversary has spent enough time inside your network and has had access to the right documentation and resources, this may be a viable attack vector. It definitely has its benefits:

  • No need to compromise multiple payment operators;
  • No requirement to compromise - or establish a foothold within - the SWIFT Secure Zone;
  • No requirement to bypass MFA and gain credentials for a messaging interface;
  • No generation of application user activity logs;
  • No payment application login alerts;
  • No bespoke app-specific and tailored malware;
  • And all the other things associated with the complex task of gaining and leveraging payment operator access.

All an attacker may need to do is compromise one specific user on the corporate network: a Message Queue administrator.

The industry is spending a lot of time and effort focused on securing their payment systems, applications, processes, and users to keep - among other things - payment operators safe, Messaging Interfaces locked down, and SWIFT systems isolated. But the reality is,; the most valuable and most powerful individual in the entire model, might just be a single administrator!

As always, a security model is only as strong as its weakest link. If you're not applying the same level of security to your wider institution, there may very well be many weak links within the wider network which chain together and lead to the comrpomise of systems which feed into your various payment environment.

I think the main thing to remember when reflecting on this research is that it did not abuse any vulnerabilities within the target institution's systems, or even vulnerabilities or weaknesses within the design of their architecture. It simply leverages the legitimate user access of the Message Queue administrators and the trust relationships that exist by design within these types of large-scale payment processing systems.

So the harsh reality is, there is no particular list of recommendations for preventing this type of attack in itself. However, the main point to drive home is that you must ensure the security of your users - and overall organisation - is of a high enough standard to protect your highest privileged users from being compromised. Things such as:

  • Strong monitoring and alerting controls for anomalous behaviour;
  • Requirements for Multi-Factor authentication for access to critical infrastructure;
  • Segregation of critical infrastructure from the wider general IT network;
  • Strong password policies;
  • Well rehearsed incident detection and incident response policies and procedures;
  • Frequent high-quality security awareness training of staff;
  • Secure Software Development training for your developers;
  • Routine technical security assessments of all critical systems and components;
  • The use of 3rd party software from reputable and trusted vendors;

However, in the context of Message Queues, there is one particular control which I think is extremely valuable: The implementation of channel specific message signing! This, as demonstrated by SWIFT's LAU control, is a good way in which to ensure the authenticity of a message.

As discussed, LAU is - as far as I know at the time of writing - a SWIFT product / message partner specific control. However it's concept is universal and could be implemented in many forms, two of which are:

  • Update your in-house application's to support message signing, natively;
  • Develop a middleware component which performs message signing on each system, locally.

This is a complex requirement as it requires considerable effort on the client’s behalf to implement either approach. However, SWIFT provides guidance within their Alliance Access Developers guide on how to implement LAU in Java, Objective C, Scala and Swift;

  1. Strip any S block from the FIN message input. Keep only blocks 1: through 5;
  2. Use the FIN message input as a binary value (unsigned char in C language, byte in Java). The FIN message input must be coded in the ASCII character set;
  3. Combine the left LAU key and the right LAU key as one string. The merged LAU key must be used as a binary value (unsigned char in C language, byte in Java). The merged LAU key must be coded in the ASCII character set;
  4. Call a HMAC256 routine to compute the hash value. The hash value must also be treated as a binary value (unsigned char in C language, byte in Java). The HMAC size is 32 bytes;
  5. Convert the HMAC binary values to uppercase hexadecimal printable characters.

An example of how this may work in the more flexible middleware solution proposed is where the original service is no longer exposed to the network, and is altered to only communicate directly with the custom "LAU-eqsue" service on its local host. This service would then sign and route the message to its respective queue.

When received, the core of the recipient payment service would seek to retrieve its messages from the queues via the "LAU-esque" signing middleware, which would retrieve the message and subsequently verify its origin and authenticity by re-calculating the signature using their shared (secret) keys. Key-pairs could further be unique per message flow. This design could allow for the signing to be used as a way to validate the origin of a message even if it had passed through multiple [local] intermediary systems.

As a final bit of creative effort, I made yet another diagram to represent what this could perhaps look like - if life was as easy as a diagram:

SWIFT Help Dark

If you made it this far thanks for reading all... ~6k words!? I hope you found some of them interesting and maybe learned a thing or two!

I'd like express our gratitude to the institution who facilitated this research, as well as specifically to the various SMEs within that institution who gave their valuable time to support it throughout.

Fineksus - SWIFT Standard Changes 2019

https://fineksus.com/swift-mt-standard-changes-2019/

Paiementor - SWIFT MT Message Structure Blocks 1 to 5

https://www.paiementor.com/swift-mt-message-structure-blocks-1-to-5/

SEPA for corporates - The Difference between a SWIFT ACK and SWIFT NACK

https://www.sepaforcorporates.com/swift-for-corporates/quick-guide-swift-mt101-format/

SEPA for corporates - Explained: SWIFT gpi UETR – Unique End-to-End Transaction Reference

https://www.sepaforcorporates.com/swift-for-corporates/explained-swift-gpi-uetr-unique-end-to-end-transaction-reference/

M DIBA - LAU for SWIFT Message Partners

https://www.linkedin.com/pulse/lau-swift-message-partners-mohammad-diba-1/

Prowide - About SWIFT

https://www.prowidesoftware.com/about-SWIFT.jsp

Microsoft - SWIFT Schemas

https://docs.microsoft.com/en-us/biztalk/adapters-and-accelerators/accelerator-swift/swift-schemas

SWIFT FIN Guru - SWIFT message block structure

http://www.swiftfinguru.com/2017/02/swift-message-block-structure.html

 

About SWIFTNet FIN messages

Integrator handling input FIN messages

Integrator generation of output FIN messages

FIN is the native SWIFT message definition. The SWIFT standards describe more than 200 FIN message types. FIN Message types include user-to-user messages and system-to-user messages. To handle FIN messages you must create SWIFT-type Business-Documents for each of the message types you want to handle.

See SWIFT-XML Business-Documents for more information.

A FIN message comprises a data file and an associated technical file. A single FIN message can contain multiple component SWIFT messages.

For detailed SWIFT-XML message format information, refer to the standards definitions available online at http://www.iso15022.org/.

Exchanging FIN messages

Integrator uses the SWIFTAlliance Access (SAA) application to access SWIFTNet FIN message exchange services. Integrator can communicate with SAA either via:

  • MQSeries through a dedicated SAA component called MQ-SA
  • Automated File Transfer

SSA, in turn, links to SWIFTNet via SAG and SNL as shown in the following graphic.

Integrator handling of input FIN messages

The following graphic shows an example Integrator integration sequence for processing a SWIFT FIN message input from SWIFTNet.

  1. Integrator receives an incoming FIN message via the Integrator JMS Connector.
  2. The Receive Activity forwards the input message to the next Activity.
  3. If the input message contains multiple SWIFT messages, you configure a FIN Splitter Stage to separate the messages into individual messages.
  4. The FIN Classifier Stage directs the FIN messages to the next Activity based on message content criteria.
  5. Messages that require data transformation or validation are directed to a Map-Stage.
  6. Integrator parses the FIN message to the SWIFT Business-Document.
  7. Integrator performs data and or format transformation on the input message via a Map-Broker in the Map-Stage.
  8. Integrator builds an output message using the output Business-Document. The output Business-Document type corresponds to the type of format you want to handle in the subsequent integration processing stages.
  9. Integrator sends the resulting message to the next Activity in the processing sequence. This could be, for example, a Send Activity that directs the message to a target application, or another Sequential Activity for additional message enhancement or transformation.

Integrator generation of output FIN messages

The following graphic shows an example Integrator integration sequence for generating a SWIFT FIN message for output towards SWIFTNet.

  1. Integrator receives an incoming message in a standard format via the appropriate connector.
  2. You can use Sequential and Classification Activities to filter the message or enhance the data content before transformation to a SWIFT FIN format.
  3. Integrator parses the input message to a Business-Document that corresponds to the message input type.
  4. Integrator performs format transformation on the message content via a Map-Broker in the Map-Stage. Integrator writes the output to a SWIFT FIN Business-Document.
  5. Integrator builds an output SWIFT FIN message using the output SWIFT FIN Business-Document. Integrator sends the resulting message to the SEND Activity.
  6. The Send Activity forwards the FIN message to SWIFTNet via MQSeries application. Integrator communicates with MQSeries via a JMS Connector.

SWIFT Error Codes

  • Article
  • 2 minutes to read

SWIFT defines many network-imposed validations against the set of financial (FIN) messages. Each validation relates to a type of check against the contents of the message, and is associated with a three-character error code. The first character of the error code implies the class of the problem detected, and is a letter. The remaining two characters denote the detail of the error (when combined with the class) and always appear as a two-digit code.

Class of errors

The following table lists the letter designations, validation type, rule change associated with each class of error, and whether or not the class of error is supported.

ClassValidation type and rule changeSupported?
C, D, ESemantic validation rules 0-299Supported
KnnInvalid code word in field nnSupported
M50Message length exceededUnsupported
M60Non-SWIFT character encounteredSupported
TText validation error codesSupported
GSpecific error codes for message user group (MUG) Textval rulesUnsupported
BSpecial error codes for value-added servicesUnsupported

All SWIFT errors should be referenced in the SWIFT User Handbook. For more information and for a complete list of SWIFT error codes, refer to the Message Format Validation Rules volume of the SWIFT User Handbook. A4SWIFT implements the rules in the September 2003 edition of this publication. You can access the SWIFT Web site at https://go.microsoft.com/fwlink/?LinkId=27885.

Validation errors

There are some codes which are defined by A4SWIFT. These error codes are used in the validation/network rules created and implemented by A4SWIFT, so there is no corresponding error code defined by SWIFT for such rules. Below table shows the error code and corresponding case in which the error is thrown. is the particular field which throws the error.

Error CodeDescription
A4SWIFT001The first character of multiline field cannot be ':' or '-' character for second and subsequent lines.
A4SWIFT002Field contains invalid value.

Note

BizTalk Accelerator for SWIFT (A4SWIFT) includes support for some legacy messages, because internal applications might use these messages. Therefore, A4SWIFT maintains the associated SWIFT rules and error codes.

More good info

Troubleshooting: Issues and ResolutionsKnown IssuesCommon terms and definitions

1 Messaging FIN Error Codes This reference guide lists the error codes and abort notifications returned by FIN in case of message validation errors or other conditions such as protocol violations or delivery issues. 22 July 2016

2 FIN Table of Contents Preface... 4 About this document... 4 Audience... 4 Significant changes... 4 Chapter 1 Introduction... 5 Chapter 2 Numeric Codes General Logout/Quit Acknowledgement Errors Re-Login Request Errors Retrieval Errors Message Status Abort Reasons FIN and General Purpose Application Session Termination Report Errors Bulk Retrieval Errors Codes Chapter 3 Alphanumeric Codes General A Codes - Re-select Error Codes B Codes - Copy Service Errors C, D, and E Codes - Conditional Semantic Error Codes G Codes - Service-specific Validation H Codes - Basic Header and Application Header Validation K Codes - Code Words Validation in Generic Fields L Codes - LOGIN Errors M Codes - Message Errors N Codes - Market Infrastructure Resiliency Service (MIRS) Errors P Codes - Protocol Errors R Codes - Re-login/Re-select Errors S Codes - System-initiated Abort Errors S Codes - Select Errors T Codes - Text Validation U Codes - User Header Validation V Codes - System Message Errors and Message Block Format Errors Error Codes

3 Table of Contents 3.18 X Codes - FINCopy Message Validation (01-27) and Delayed NAK Error Codes (30-99) Y Codes - UNK Error Codes Z Codes - Trailer Validation Chapter 4 FIN Errors Introduction Abort Codes Diagnostic Codes for SS Diagnostic Codes for SA Legal Notices July

4 FIN Preface About this document Audience This reference guide lists the error codes and abort notifications returned by FIN in case of message validation errors or other conditions such as protocol violations or delivery issues. This book describes the FIN Error Codes. It should be read by: users who wish to gain an understanding of the FIN service developers who need background information on elements of FIN The reader is expected to have an understanding of FIN messaging, which is described in the FIN Service Description and the FIN Operations Guide. For more information about the rules, the reader must consult the Message Format Validation Rules. Significant changes The following tables list all significant changes to the content of FIN Error Codes since the 24 July 2015 edition. These tables do not include editorial changes that SWIFT makes to improve the usability and comprehension of the document. New information Addition of error codes E20, E88, E98, E99, T49, and T69 (no longer available) Addition of error code G27 Addition of error code U12 Location Error codes E20, E88, E98, E99, T49, and T69 G27 U12 Updated information Update text of error codes B05, C06, C08, C20, C28, C38, C39, C41, C71, C72, D07, D24, D31, D45, D59, D99, E04, E34, E39, E41, E42, E77, E78, E80, T09, T14, T22, T26, T39, T66, T94, T95, T96, U00, U09, X20, and X35 Location Section 3.3, B Codes - Copy Service Errors Section 3.4.1, C Error Codes Section 3.4.2, D Error Codes Section 3.4.3, E Error Codes Section 3.15, T Codes - Text Validation Section 3.16, U Codes - User Header Validation Section 3.18, X Codes - FINCopy Message Validation (01-27) and Delayed NAK Error Codes (30-99) 4 Error Codes

5 Chapter 1 Introduction Chapter 1 Introduction The FIN error codes are divided into the following groups: Validation error codes Conditional semantic error codes Abort error codes All input messages are validated for syntax and semantic errors by the system. If there is an error, a validation error code is returned in the logical (negative) acknowledgement or in an MT 019 Abort Notification. Abort error codes give the reason why an application or the logical connection has been discontinued. They are generated following the recognition of a certain condition and not necessarily due to errors in a message. Abort error codes can come from the system or from a user's terminal. For reference purposes, the error codes have been placed in two chapters. Chapter 2, Numeric Codes, contains all the errors that are represented by two- or three-digit codes. Error codes in Chapter 3, Alphanumeric Codes, have the following format: <code><nn> where <code> is a letter designating the error type and <nn> identifies the particular error. Where two or more variants of a message exist, for example, MT 103, MT 103 STP, and MT 103 REMIT, each variant is referenced independently in an error code description. This means that mention of the MT 103 refers only to the generic variant of the MT 103 and does not include either the MT 103 STP or the MT 103 REMIT. 22 July

6 FIN Chapter 2 Numeric Codes 2.1 General Numeric codes are used for: Logout/Quit Acknowledgement errors (field 401) Re-Login Request errors (fields 280, 331 and 333) Retrieval errors (field 421) Message status (field 431) Abort reasons (field 432) FIN and General Purpose Application session termination (field 443) Report errors (field 461) 2.2 Logout/Quit Acknowledgement Errors The following error codes are returned in field 401 of Logout and Quit acknowledgements. Logout and Quit Commands are always positively acknowledged and the session (General Purpose Application or FIN) closed. However, one of the following error codes can be included in the acknowledgement. 01 Incorrect time/day The Logout Command can include the time/day inhibitor which prevents the next Login occurring before the time/day specified. The time/day in the format DDHHMM cannot be more than 7 days after the current date. 02 Training trailer missing The trailer block is only present if the message is sent by a training logical terminal. If the Logout Command is sent from a training logical terminal, it must contain a Training trailer. 03 Input sequence number error Each message sent from a logical terminal has an input sequence number. The first message sent in the General Purpose Application will always have an input sequence number of , whereas the first message sent in FIN will have an input sequence number value of the last input sequence number+1 sent from that logical terminal. This error will be returned in the acknowledgement of a Logout or Quit Command when the input sequence number of that command is incorrect. 2.3 Re-Login Request Errors The following error codes are returned in fields 331, and 333 of acknowledgements, session history reports, and daily check reports: 010 Re-Login Request received while logical terminal is active on the Logical Terminal Control association 6 Error Codes

74 Retrieval Errors The following codes are returned in field 421 of message retrievals: 000 Message has no text block 002 Message was encrypted and no key or the wrong key was supplied by the user 22 July

8 FIN 003 Empty report (no messages found) 004 Logical terminal is not authorised to retrieve the message, that is the requester is neither the sender nor the receiver of the original message 005 Text lost due to Slice Processor recovery 006 History lost due to Slice Processor recovery 007 Target message is a retrieval report (MTs 021 or 023) 010 Invalid MT received by Slice Processor pseudo logical terminal (system) 011 Invalid <application-id> received by Slice Processor pseudo logical terminal (system) 012 Invalid date in retrieval criteria tag (system) 013 Invalid time in retrieval criteria tag (system) 014 End daytime before start daytime 015 Target message older than 124 days (for range retrieval, daytime used) 016 <branch-code> is not 'XXX' 018 Invalid destination for report (tag 102). The logical terminal must have the same destination as the sender of the retrieval request or be a SWIFT logical terminal, and must be enabled for the application in which the retrieval message is to be sent 019 Invalid input retrieval by receiver or output retrieval by sender (only single message input reference/message output reference allowed) 020 Invalid synonym retrieval (synonym is not sender or receiver of message) 021 Unknown target logical terminal 022 Request received at wrong Slice Processor (system) 023 Could not retrieve message input reference in message output reference retrieval (system) 032 No delivery attempt in message input reference retrieval by receiver 033 On-line text read error (system) 034 On-line history read error (system) 8 Error Codes

9 Chapter 2 Numeric Codes 035 Text read error from archival (system) 036 History read error from archival (system) 037 Partial report - major system recovery in progress 038 Unable to retrieve text and history from archival because of system problems 040 The limits for group retrieval (99 messages in one request) have been exceeded 041 Message could not be decrypted (system) 043 The logical terminals in the beginning message input reference/message output reference and the ending message input reference/message output reference in a range retrieval request are not the same, in tag 252 (message input reference range) or 254 (message output reference range) 044 Illogical use of field 152 <1st-isn> or field 153 <1st-osn>. input sequence number or output sequence number already included as component in message input reference(s) or message output reference(s) 045 Message text not retrievable (message not successfully delivered) 046 Off-line retrieval not allowed for Test and Training messages 047 The text of local test mode messages is not retrievable 048 Retrieval message too long 049 Retrieval period specified exceeds 10 days 099 Retrieval report problem. Contact your Customer Support Centre 2.5 Message Status The message status is returned in field 431 of non-delivery warnings, undelivered message reports, and retrieved messages. 01 Delivered 02 Rejected by destinee 04 Aborted 22 July

10Abort notification MT 019 contains an alphanumeric abort code 10 Error Codes

11 Chapter 2 Numeric Codes These codes are specific to each FINCopy service. Contact your respective service provider for the meaning of each code within the range For Euro Banking Association (EBA) Processing, only the following codes are used: 70 Refusal from the Clearing Computer, and delivery aborted; the Sender of the payment message should also receive an MT 998 / SMT n75 Error Message from the Clearing Computer giving further reasons for the refusal. 71 Refusal from the Clearing Computer because of a message format error that prevented normal processing, and delivery aborted. 99 System error 2.6 Abort Reasons The following codes are returned in field 432 of abort notifications and, for the FINCopy service, Message Refusals: 01 Message too old (remained undelivered for n days) 02 Too many unsuccessful delivery attempts 03 Destination disabled 04 Operator aborted 05 Message could not be recovered after a major system failure because it was user encrypted 06 Message type incompatible with the FIN interface mode 11 Message is too old, but was authorised 12 Too many delivery attempts, but message was authorised 13 Destination is disabled, but message was authorised 14 Message is too long, but was authorised 21 Message is too old and was bypassed 22 Too many delivery attempts and the message was bypassed 23 Destination is disabled and the message was bypassed 24 Message is too long and was bypassed 22 July

12 FIN 29 Message held for approval prior to Bypass mode and aborted 32 Message is too old and was not authorised 33 Copy message to the copy service server was aborted 35 FINCopy service parameter(s) incorrectly defined in FIN 50-ZZ 99 is pre-defined as 'system error'. All other alphanumeric codes (combination of 0-9 and A-Z) are specific to each FINCopy service. Contact your respective service provider for the meaning of each code. Code S1 is used by the Sanctions screening service to indicate that the message has been aborted on request of the subscribing user. Note: All undefined numeric codes are reserved for use by FIN. 2.7 FIN and General Purpose Application Session Termination The following codes are returned in field 443 of Service Message 14 (for further details see FIN System Messages): 000 Normal termination 001 Application Control or Logical Terminal Control has aborted 002 Application Control or Logical Terminal Control has terminated normally 004 System timed out message output reference ACK 006 QUIT or LOGOUT received while outstanding input messages 007 Input message/service message after reception of a QUIT or LOGOUT 008 Input window violation (more outstanding input messages than window size) 009 System timed out on association establishment 010 Reception of a SELECT from a logical terminal that already has a FIN session 011 Association establishment request failed authentication 014 Message output reference ACK Basic Header error 015 Too many messages input in a session. Maximum is Error Codes

13 Chapter 2 Numeric Codes 016 Too many messages output in a session. Maximum is Message output reference ACK from wrong synonym 025 As for 052 but due to receipt of a Re-Login Request, rather than a Login Request 051 As for 052 but on a different Regional Processor 052 Reception of a login from a logical terminal for which the system has already processed a login transmitted over a different Logical Terminal Control on the same Regional Processor. The existing session is aborted and the new session established. 053 SELECT with bad text block 054 AP ABORT REQUEST with bad text block 2.8 Report Errors The following codes are returned in field 461 of Delivery Subset Status Reports, Undelivered Message Reports, and Undelivered SSI Update Notification Reports: 001 Empty report 002 End of undelivered report 003 System undergoing major recovery or system not completely synchronised yet 004 Too many undelivered messages 005 User on fall back Regional Processor, cannot generate report 006 The message referenced in the request could not be found. 007 Invalid destination for report. The sender of the request must be the same as the sender of the message referenced in the request. 008 No MTs 671 were found for the referenced MT Requesting logical terminal in invalid state 016 Branch code is not "XXX' 099 System internal problems, contact your Customer Support Centre 22 July

14 FIN 2.9 Bulk Retrieval Errors Codes The following codes are returned in field 144 of Bulk Retrieval Responses (MT 025): 03 Retrieval only partially complete 11 Invalid <start-date-time> 12 Invalid <end-date-time> 13 Invalid retrieval time range 14 Retrieval aborted due to system error 15 Retrieval aborted due to communication error 16 Retrieval aborted due to system recovery 17 Retrieval aborted by SWIFT 19 Retrieval complete The text of messages that were sent to the retrieving BIC more than 124 days ago cannot be retrieved. If those messages were received by the retrieving BIC less than 124 days ago, the file contains the message output reference of the history and the message input reference of the text. 20 Retrieval aborted due to system error (Test and Training destination - attempt to use tape) 21 Retrieval aborted due to system error (FIN/FIN Bridge key error) 22 Retrieval aborted due to system error (missing master BIC) 14 Error Codes

15 Chapter 3 Alphanumeric Codes Chapter 3 Alphanumeric Codes 3.1 General This chapter contains the codes for the following error types: Code Error Type Code Error Type A Abort at Application Interface Level Errors P Protocol Errors A Re-select Errors R Re-login/Re-select Errors B Copy Service Errors S System-initiated Abort Errors C Dialout Errors S Select Errors C, D and E Conditional Semantic Errors T Text validation (Block 4) Errors G Service-specific Validation Errors U User Header Validation Errors H Basic Header and Application Header Validation Errors U User Abort Errors K Code Words Errors in Generic Fields V System Message or Message Block Format Errors L LOGIN Errors X Delayed NAK Errors and FINCopy Service Message Refusals M Message Errors Y User Negative Acknowledgement Errors N Market Infrastructure Resiliency Service (MIRS) Errors Z Trailer Validation Errors Note: Similar error codes are used by other SWIFT services, such as Accord, or Processing for Euro Banking Association (EBA), and can have different meanings. The error codes used by each of the services are described in the respective service documentation. 3.2 A Codes - Re-select Error Codes A56 Re-select NAK error code (in field tag 503) to indicate that the logical terminal is not in a recoverable state. The FIN interface should execute a fresh select procedure. 3.3 B Codes - Copy Service Errors B01 Message contains Value-Added Service server id but sender or receiver, or both, are not members of the service. B02 Available. B03 103:TPS is present in the message but the sender is not a member of TPS, or the message is not allowed for TPS. 22 July

16 FIN B04 Available. B05 A system error has occurred. Contact your local Customer Support Centre for further information. 3.4 C, D, and E Codes - Conditional Semantic Error Codes Note Where a natural language expression would be too difficult to synthesise or too long, a matrix is provided. The row and column headers identify the elements involved (for example, field tags, code words, letter options). Matrices should be read from left to right and from top to bottom C Error Codes C00 Not used. C01 MTs 102, 102 STP, 104, and 107 If field 19 is present in sequence C, then it must equal the sum of the amounts in all occurrences of field 32B in sequence B. MTs 201, 203, 204, and 559 The amount in field 19 must equal the sum of the amounts in all occurrences of field 32B or 34A. MT 256 If field 19 is present in sequence C, then it must equal the sum of the amounts in all occurrences of field 32J in sequence B. MT 824 Field 19 at the completion of each outer repetitive sequence must equal the sum of the products of subfields 1 and 3 in all occurrences of field 68A from its respective inner repetitive sequence(s). C02 The currency code must be the same for all occurrences of indicated fields in the entire message. See the Standards MT Message Reference Guides for the indicated fields in each message. Examples: The following list (not exhaustive) explains how error code C02 is applied in specific message types: MT 321. The currency code in the amount fields (fields 19A in sequence B) must be the same for all occurrences of this field in the message. MTs 320 and 330. The currency code in the amount fields, except for fields 33B and 33E in sequence G, must be the same for all occurrences of these fields in the message. MT 350. The currency code in the amount fields 32B and 34B in sequence B must be the same. 16 Error Codes

17 Chapter 3 Alphanumeric Codes Special Cases: The following MTs (not an exhaustive list) apply error code C02 in an exceptional manner (for example, either based on the presence of another field OR individually to separate groups of fields within the MT): MTs 103, 103 REMIT, and 103 STP. If field 71G is present, the currency code in the fields 71G and 32A must be the same. MTs 104 and 107. The currency code in fields 32B and 71 G in sequences B and C must be the same for all occurrences of these fields in the message. The currency code in field 71F in sequences B and C must be the same for all occurrences of this field in the message. MT 320. The currency codes in the amount fields 32B, 32H, and 34E in sequence B, and field 71F in sequence H, must be the same. MT 620. If field 32H is present, then the currency code must be the same as the currency code in field 32B. C03 The number of decimal digits in the amount component is checked against the maximum allowed for the corresponding currency. This check is mostly applied to fields that contain both the amount and the currency code components. Examples: field 32A in MTs 103, 103 REMIT, 103 STP and in MT 256, sequence C field 32B in MTs 104 and 107, sequences B and C This check also applies, among others, to: field 19 in MTs 102, 102 STP, 104, 107, 201, 203, 204, and 559 where the corresponding currency is the one used in field 32B or 34A field 19 in MT 824 where the corresponding currency is the one used in corresponding occurrences of field 68A field 32J in sequence B, and to field 19 in sequence C, in MT 256 where the corresponding currency is the one used in field 32A field 33B in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequence B field 71F in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequences B and C field 71G in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequences B and C field 72 Reject/Return in MTs 103, 103 REMIT, 103 STP and in MTs 104 and 107, sequence A Note: Error code C03 should be applied only to field 68A in MT 824 if subfield 5 is present. C04 MTs 503, 504, and 506 In sequence B, if field :19B::TEXA is not present, then field :19B::TCRL is mandatory; otherwise field :19B::TCRL is optional. Sequence B If field :19B::TEXA is... Then field :19B::TCRL is July

18 FIN C05 Identifier Code must be a financial institution BIC. This error code applies to all types of BICs referenced in a FIN message, including connected BICs, non-connected BICs, Masters, Synonyms, Live destinations and Test & Training destinations. See the table below for the list of MTs affected. MT Field Sequence(s) Qualifier Comments A 56A 57A 52A A, B B B A, B 53A 54A 57A C C B The same validation applies to the MT 102 and the MT 102 STP A 53A 54A 55A 56A The same validation applies to the MT 103, MT 103 REMIT, and the MT 103 STP 57A A 53A 57A A, B C B Note: For sequence C, see also error code C A A, B 53A C 57A B A 53A 54A 111, A 200, , A 57A 52A 53A 54A 56A 57A 18 Error Codes

19 Chapter 3 Alphanumeric Codes MT Field Sequence(s) Qualifier Comments 58A 202 COV COV A 53A 54A 56A 57A 58A 52A 56A 57A 53A 57A 58A 52A 53A 56A 57A 58A 52A 53A 56A 57A 58A 52A 56A 57A 51A 52A 52G 56A 57A 58A A A A A A A B B B B A A A A A A A B B B A A A B B B A 22 July

20 FIN MT Field Sequence(s) Qualifier Comments 56A A C AJ 56AJ 57AJ 53AJ 56AJ 57AJ 53AJ 56AJ 57AJ 53A 56A 57A 53AJ 56AJ 57AJ 84AJ 86AJ B1, B2, D B1, B2, D B1, B2, D D1, D2, D3 D1, D2, D3 D1, D2, D3 B, E B, E B, E C, E, L C, E, L C, E, L B C, E, L P B3a CDEA INTE ACCW 95P D1 CDEA INTE ACCW AJ 56AJ 57AJ 86AJ C, D, E, F, I C, D, E, F, I C, D, E, F, I C, D, E, F, I P C1 CDEA INT2 INTE ACCW AJ 56AJ 57AJ 86AJ 53AJ 56AJ C, D, E, F C, D, E, F C, D, E, F C, D, E, F C, D, F C, D, F 20 Error Codes

21 Chapter 3 Alphanumeric Codes MT Field Sequence(s) Qualifier Comments 341, AJ 86AJ 53AJ 56AJ 57AJ 86AJ 53A 56A 57A 86A C, D, F C, D, F C C C C D, G, L, M D, G, L, M D, G, L, M D, G, L, M A D, G, K, L, M, N 56A D, G, K, L, M, N 57A D, G, K, L, M, N 86A D, G, K, L, M, N A 56A 57A 86A 53A 56A 57A 86A 53A 56A 57A 86A C, E C, E C, E C, E L, M L, M L, M L, M J, K, L, M J, K, L, M J, K, L, M J, K, L, M P B1 ACCW INT1 INT A 53A 54A 57A 22 July

22 FIN MT Field Sequence(s) Qualifier Comments 58A A A 450, 455, A P C2 ACCW INTM PAYE P C2a1, E1 ACCW INTM PAYE P B2a1, D1 ACCW INTM PAYE P B1b1 ACCW INTM PAYE P D2 ACCW INTM PAYE P C2 ACCW INTM PAYE P D2 ACCW INTM PAYE A B P C2 ACCW INTM PAYE 540, 541, 542, 543, 544, 545, 546, P E2 ACCW INTM PAYE A P D2a ACCW P E2 ACCW INTM PAYE A 56A 57A 86A 87A 53A 56A 57A 86A 87A 86A 87A B B, C B, C B, C B, C 22 Error Codes

23 Chapter 3 Alphanumeric Codes MT Field Sequence(s) Qualifier Comments A 87A A A 53AJ 56AJ 57AJ 86AJ C, D, E, F C, D, E, F C, D, E, F C, D, E, F A B, C A B A C P B1 ACCW INT1 INT A 42A 51A 53A 57A A 57A A A 42A 51A 52A 53A 57A A 42A 52A 57A 730, A A 22 July

24 FIN MT Field Sequence(s) Qualifier Comments 42A 58A A 57A 58A A A 54A A 57A 58A A 54A 768, A 51A 52A 53A 54A A A 53A 54A A A A 56A A n90 n91 52A 52A 57A C06 MT 210 Either field 50a or field 52a, but not both, must be present in a repetitive sequence. 24 Error Codes

25 Chapter 3 Alphanumeric Codes MTs 710 and 720 Either field 52a or field 50B, but not both, must be present. If field 52a is... Then field 50B is... MT 910 Either field 50a or field 52a must be present. C07 MT 516 Either field 35A or 35N must be present. C08 In fields listed below, the codes XAU, XAG, XPD, and XPT are not allowed, as these are codes for commodities for which the category 6 commodities messages must be used. MT Field Sequence(s) B B STP 32B 32A 32B 32A B C B C A 103 REMIT 32A 103 STP 32A A B A 202 COV 32A A B A 205 COV 32A A B B B B 33B 71F 32B B1 B2 C D B B1 22 July

26 FIN MT Field Sequence(s) B 32G 34B 32G 32B 33B 34a 34B 32B 33B 33E 32Q 32E 71F 32H B2 D D E A A A B1 D D E G H K L C09 MT 430 In each occurrence of sequence A, if field 33a is present, then field 32a must be present. C10 MT 422 At least one of the fields 72, 75 or 76 must be present. C11 MT 400 If field 57a is present, fields 53a and 54a must be present. C12 MTs 707 and 747 When field 32B or 33B is present, field 34B must be present. Conversely, when field 34B is present, either field 32B or field 33B must be present. C13 MT 750 If any of fields 33B, 71B, or 73 is present, field 34B must be present. C14 MTs 559 and 754 Either field 53a or 57a, but not both, may be present. C15 MT 747 At least one of the fields 31E, 32B, 33B, 34B, 39A, 39B, 39C, 72, or 77A must be present. 26 Error Codes

27 Chapter 3 Alphanumeric Codes C16 MT 707 If field 23 is present, field 52a must be present. C17 MT 734 If field 73 is present, field 33a must be present. C18 MT 752 If fields 32B and 71B are present, field 33a must be present. C19 MT 754 Either field 72 or field 77A, but not both, may be present. C20 MT 304 In sequence D, field 30F may only be present if field 34B is present. MT 601 Field 53a may be present only if field 34P is present. C21 MT 506 If sequence C is not present, then sequence D is mandatory. If one or more occurrence of sequence C is/are present, then sequence D is optional. If sequence C is... Then sequence D is... (once or more) C22 MT 920 If field 12 contains the value '942', at least field 34F Debit/(Debit and Credit) Floor Limit Indicator must be present in the same repetitive sequence. C23 MTs 920 and 942 When only one field 34F is present, subfield 2 must not be used. When both fields 34F are present, subfield 2 of the first 34F must contain D, and subfield 2 of the second 34F must contain C. In MT 920, this applies to each repetitive sequence. C24 MT 940 If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61. MT 942 If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61. Note: This rule does not apply for the field 86 if it is the last field in the message. When field 86 is the last field in the message and it is not preceded by a field 61, then it is considered to provide information about the message as a whole. 22 July

28 FIN C25 MT n92 Field 79 or a copy of at least any fields of the original message or both must be present. If field 79 is... Then copy of any field(s) of original message is... (that is, minimum one field, any field) Note: SWIFT does not validate the relationship between the copied fields and the original message, hence, any valid field is correct. The system will negatively acknowledge the MT n92 with error code C25 if there is no field after field 11S. C26 MT 430 At least one of the optional fields 32a or 74 must be present. C27 MTs 940, 941, 942, 950, 970, and 972 The first two characters of the three-character currency code in fields 60F, 60M, 62F, 62M, 64, 65, 90C, and 90D, in MTs 940, 941, 942, 950, 970 and 972, and field 34F in MT 942 must be the same for all occurrences of these fields. C28 MTs 541, 543, and 578 A value date must only be provided for cash/securities split settlement. That is, in any occurrence of subsequence E3, if value date field :98a::VALU is present, then in sequence E field :22F::STCO//SPST must be present, and settlement amount field :19A::SETT must be present in the same subsequence E3. In any occurrence of subsequence E3 if field :98a::VALU is... Sequence E then field :22F::STCO//SPST (with DSS not present) In the same occurrence of subsequence E3 and field :19A::SETT is... MTs 544, 545, 546, and 547 A value date must only be provided with an effective settlement amount, that is, in any occurrence of subsequence E3, if value date field :98a::VALU is present, then settled amount field :19A::ESTT must be present in the same subsequence. Subsequence E3 If field :98a::VALU is... Then field :19A::ESTT is... Note: MTs 544, 545, 546, and 547, see also error code E87. MTs 545 and 547, see also error code E Error Codes

29 Chapter 3 Alphanumeric Codes MT 586 A value date must only be provided for cash/securities split settlement. That is, in any occurrence of subsequence B5b, if value date field :98a::VALU is present, then in subsequence B5 field :22F::STCO//SPST must be present, and settlement amount field :19A::SETT must be present in the same subsequence B5b. In any occurrence of subsequence B5b if field :98a::VALU is... Subsequence B5 then field :22F::STCO//SPST (with DSS not present) is... In the same occurrence of subsequence B5b and field :19A::SETT is... C29 Available. C30 MT 707 At least one of the fields 31E, 32B, 33B, 34B, 39A, 39B, 39C, 44A, 44E, 44F, 44B, 44C, 44D, 79, or 72 must be present. C31 MTs n95 and n96 Either field 79 or a 'copy of any field(s) of the original message to which this message relates', but not both, may be present. Note: SWIFT does not validate the relationship between the copied fields and the original message; hence any valid fields are accepted. C32 MTs 300, 303, 304, 305, 306, 320, 330, 340, 341, 350, 360, 361, 362, 364, 365, 600, 601, 620, and 643 An optional sequence of fields was used. However, a field that is required (that is, indicated by an 'OR') or a field that is mandatory (that is, indicated by ' in...') within this sequence is missing. C33 MTs 768 and 769 If field 71B is present, field 32a must be present. C34 MT 769 Either field 33B or 39C, but not both, must be present. C35 MTs 643, 644, 646, and 649 Either field 21 or 29B must be present. C36 MTs 643 and 646 Subfield 2 (<DATE2>) of field 31F must be present in each occurrence of sequence B. C37 MT 577 Subfield 2 (<DATE2>) of field 67A must not be present. 22 July

30 FIN C38 MT 306 In sequence I, if field 12G contains the code BERM, then field 30T and field 22Y must be present. C39 MT 306 In sequence I, if field 12G contains the code AMER, then field 30Y must be present. C40 MT 920 The currency code must be the same for each occurrence of field 34F within each repetitive sequence. C41 MT 306 The presence of sequence J, subsequence J1, subsequence J2, and field 14B in sequence J depends on the value of field 12F in sequence A, as follows: Sequence A if field 12F is... Then sequence J is... Then subsequence J1 is... Then subsequence J2 is... Sequence J then field 14B is... AVRF AVRO AVSF AVSO DAVF DAVO Any other value Not applicable Not applicable Not applicable C42 MT 824 The currency code in each of the fields 68A of a sequence of fields 68A preceding a field 19 must be the same. C43 MT 646 Either field 32N or 33N must be present. C44 MT 646 If fields 32N and 33N are present in sequence C, field 34a must be present in sequence C. C45 MT 646 If field 23 contains REPRINC or PREPRINC, field 32N must be present in sequence C. C46 MT 646 If field 23 contains INT, field 33N must be present in sequence C. 30 Error Codes

31 Chapter 3 Alphanumeric Codes C47 MT 643 If field 23 contains LOAN/DRAWDOWN or FINARR/DRAWDOWN, sequence B must not be present. C48 MT 643 If field 23 contains LOAN/RENEWAL or FINARR/RENEWAL, sequence B must be present. C49 MT 456 If field 71B is present, the values in fields 32a and 33D must be different. C50 MTs 540, 541, 542, and 543 If field :36B: is present in minimum one occurrence of sequence A1, then the type of settlement transaction must be a pair-off or a turn-around, that is, sequence E field :22F::SETR//PAIR or :22F::SETR//TURN must be present. 1 if field :36B: is... Sequence E then field :22F::SETR must be... :22F::SETR//PAIR and DSS must not be present or :22F::SETR//TURN and DSS must not be present Not applicable C51 MT 643 If field 23 contains LOAN/DRAWDOWN or LOAN/RENEWAL, field 31R must be present. C52 MT 361 In sequence A, the presence of field 32B depends on field 23A, as follows: If field 23A is... Then field 32B is... CORRBUYER CORRSELLER VOLABUYER VOLASELLER Any other value C53 MT 643 If field 71C is present in any sequence B, field 34a must be present in the same sequence. C54 MT 644 Either field 36 or field 37(A-F) must be present in any sequence B. 22 July

32 FIN C55 MT 644 In any sequence B, the currency code in fields 33B and 34a must be the same. C56 MT 300 In sequence E, the presence of field 22Q depends on field 17Z as follows: Sequence E If field 17Z is... Then field 22Q is... Y N MTs 305 and 601 In sequence B, the presence of field 22Q depends on field 17Z as follows: Sequence B If field 17Z is... Then field 22Q is... Y N MT 306 In sequence M, the presence of field 22Q depends on field 17Z as follows: Sequence M If field 17Z is... Then field 22Q is... Y N MT 340 In sequence G, the presence of field 22Q depends on field 17Z as follows: Sequence G If field 17Z is... Then field 22Q is... Y N MTs 341 and 600 In sequence D, the presence of field 22Q depends on field 17Z as follows: 32 Error Codes

33 Chapter 3 Alphanumeric Codes Sequence D If field 17Z is... Then field 22Q is... Y N MT 360 In sequence O, the presence of field 22Q depends on field 17Z as follows: Sequence O If field 17Z is... Then field 22Q is... Y N MT 361 In sequence P, the presence of field 22Q depends on field 17Z, as follows: Sequence P If field 17Z is... Then field 22Q is... Y N C57 MT 646 If field 34N is present in any sequence B, field 31F in the same sequence B and field 33N in sequence C must be present. C58 MT 300 In field 77D of sequence A, if the code /VALD/ is present, then it must appear in the first 6 characters of the first line and in no other place, and it must be followed by a date expressed as YYYYMMDD and the "end_of_line" separator, that is, ":77D:/VALD/"YYYMMDD"CrLf". See also error code C59. MT 304 In field 72 of sequence C, if the code /VALD/ is present, then it must appear in the first 6 characters of the first line and in no other place, and it must be followed by a date expressed as YYYYMMDD and the "end_of_line" separator, that is ":72:/VALD/"YYYMMDD"CrLf". See also error code C59. MT 305 In field 72 of sequence A, if the code /VALD/ is present, then it must appear in the first 6 characters of the first line and in no other place, and it must be followed by a date expressed as YYYYMMDD and the "end_of_line" separator, that is ":72:/VALD/"YYYYMMDD"CrLf". See also error code C July

34 FIN MT 646 If field 34N is present in any sequence B, the total amount given in field 33N must equal the total amount of all occurrences of field 34N amounts in sequence B. C59 MT 300 In sequence A, if field 77D is present, then: if the first six (6) characters of the first line are equal to /VALD/, then the second line must be present and it must contain "/SETC/" in the first six (6) characters, followed by a valid ISO 4217 currency code and the end of line separator, that is, "/SETC/"<CUR>"CrLf". if the first six (6) characters of the second line are equal to /SETC/, then the first six (6) characters of the first line must be equal to /VALD/. the code "/SETC/" is not allowed in any other place than the first six (6) characters of the second line. if the first six (6) characters of the third line are equal to /SRCE/, then the first six (6) characters of the second line must be equal to "/SETC/". the code "/SRCE/" is not allowed in any other place than the first six (6) characters of the third line. See also error code C58. MT 304 In sequence C, if field 72 is present, then: if the first six (6) characters of the second line are equal to /SETC/, then it must be followed by a valid ISO 4217 currency code and the end of line separator, that is, "/SETC/"<CUR>"CrLf". if the first six (6) characters of the second line are equal to /SETC/, then the first six (6) characters of the first line must be equal to "/VALD/". the code "/SETC/" is not allowed in any other place than the first six (6) characters of the second line. if the first six (6) characters of the third line are equal to /SRCE/, then the first six (6) characters of the second line must be equal to "/SETC/". the code "/SRCE/" is not allowed in any other place than the first six (6) characters of the third line. See also error code C58. MT 305 In sequence A, if field 72 is present, then: MT 321 if the first six (6) characters of the first line are equal to /VALD/, then the second line must be present and it must contain "/SETC/" in the first six (6) characters, followed by a valid ISO 4217 currency code and the end of line separator, that is, "/SETC/"<CUR>"CrLf". if the first six (6) characters of the second line are equal to /SETC/, then the first six (6) characters of the first line must be equal to "/VALD/". the code "/SETC/" is not allowed in any other place than the first six (6) characters of the second line. In sequence B, the presence of field 19A and of the Next Interest Due Date (field :98A::INTR) depends on the Type of Loan/Deposit Event (field :22H::TLDE) in sequence A as follows: 34 Error Codes

35 Chapter 3 Alphanumeric Codes if field :22H::TLDE is... Then field :98A::INTR is... And field :19A::SETT is... Sequence B And field :19A::RODI is... And field :19A::CINT is... And field :19A::NINT is... CONF ROLL MATU MT 800 The amounts in fields 34B and 32A must be the same. C60 MT 307 In sequence A, the presence of field :22H::APER and the presence of field :22H::NEGR depends on the field :22H::CRTR as follows: If field :22H::CRTR is... Then field :22H::APER is... And field :22H::NEGR is... ASET AFWD MT 321 In sequence A, the presence of field :99B:: depends on the presence of field :22H::BLOC as follows: If field :22H::BLOC is... Then field :99B:: is... MT 643 In each sequence B, the currency code in fields 32P, 33a and 34a must be the same. C61 MT 307 In sequence A, the presence of field :22H::PAFI depends on field :22H::APER as follows: If field :22H::APER is... Then field :22H::PAFI is... OPEF NOPE Field :22H::APER not present MT 321 In sequence B, the presence of field :98A::LDFP depends on the value of field :22H::TLDE in sequence A as follows: 22 July

36 FIN if field :22H::TLDE is... Sequence B then field :98A::LDFP is... MATU Not MATU MT 643 In each sequence C, the currency code in fields 32B and 33B must be the same. C62 MT 307 The presence of sequence C depends on field :22H::APER as follows: if field :22H::APER is... Then sequence C is... OPEF NOPE Field :22H::APER not present MT 321 In sequence B, the presence of field :99B::DAAC depends on the presence of field :98A::LDFP as follows: Sequence B If field :98A::LDFP is... Then field :99B::DAAC is... C63 MT 307 In sequence A, the presence of the qualifier UNKN in field :22H::NEGR//UNKN depends on the content of field :22H::CRTR, of field :22H::APER and of field :22H::PAFI as follows: CRTR//ASET if field :22H:: is... CRTR//AFWD and APER//OPEF CRTR//AFWD and APER//NOPE and PAFI//PAIN CRTR//AFWD and APER//NOPE and PAFI//FINA Then field :22H::NEGR//UNKN is... MT 321 In sequence A, if field 99B is present, then all qualifiers must be present. C64 MT 307 The presence of sequence D depends on the value of field 22H as follows: 36 Error Codes

37 Chapter 3 Alphanumeric Codes If field :22H::CRTR is... And field :22H::APER is... And field :22H::PAFI is... And field :22H::NEGR is... Then sequence D is... ASET Not applicable per error code C60 Not applicable per error code C61 NETC ASET Not applicable per error code C60 Not applicable per error code C61 GRSC ASET Not applicable per error code C60 Not applicable per error code C61 AFWD OPEF Not applicable per error code C61 NETC or GRSC or UNKN AFWD NOPE PAIN NETC or GRSC or UNKN AFWD NOPE FINA NETC AFWD NOPE FINA GRSC C65 MT 567 If the message is a cancellation request status (:23G:CAST), then, in every occurrence of sequence A2 Status, a cancellation processing status must be reported (:25D::CPRC...). If the message is an instruction status (:23G:INST) then, in every occurrence of sequence A2 Status, an instruction processing status (:25D::IPRC...) must be reported. If the message is corporate action event processing status (:23G:EVST), then, in every occurrence of sequence A2 Status, an event status (:25D::EPRC...) must be reported. if field 23G is... Then, in every occurrence of sequence A2 field :25D must be... CAST INST EVST :25D::CPRC... :25D::IPRC... :25D::EPRC... C66 MT 643 The number of occurrences of sequence C must be equal to or greater than the number of occurrences of sequence B. C67 MT 516 In sequence A, either field 83C or 87a but not both, may be present. C68 MTs 202 COV and 205 COV In sequence B, if field 56a is present, then field 57a must also be present. 22 July

38 FIN C69 MT 507 In each occurrence of sequence B, if present, if subsequence B1 is present, the presence of subsequences B1a and B1b depends on the value of field :22H::COLL in sequence B as follows: Sequence B (each occurrence) If subsequence B1 is... And field :22H::COLL//Status is... Then subsequence B1a is... And subsequence B1b is... CCOL SCOL BCOL (Not applicable see also error code C70) Not applicable Not applicable Not applicable Not applicable Not applicable Note: Error code C70 takes precedence over error code C69. C70 MT 507 In each occurrence of sequence B, the presence of subsequence B1 depends on the value of fields :25D::COLL//<Status> and :22H::COLL//<Indicator> as follows: Sequence B (each occurrence) If field :25D::COLL/[8c]/4!c Data Source Scheme [8c] is... And field :25D::COLL/[8c]/4!c is... And field :22H::COLL//4!c is... Then subsequence B1 is... :25D::COLL//ACCT BCOL :25D::COLL//ACCT :25D::COLL//ACCT CCOL SCOL [1] [1] :25D::COLL//REJT Not applicable Not applicable BCOL CCOL [1] SCOL [1] [1] See also error code C69 for additional checks. Error code C70 takes precedence over error code C69. C71 MT 535 In each occurrence of subsequence B1, field :93B::AGGR cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. 38 Error Codes

39 Chapter 3 Alphanumeric Codes Subsequence B1 if field :93B::AGGR is... Repeated Then one occurrence of :93B::AGGR must be... :93B::AGGR//FAMT and DSS must not be present And the other occurrence of :93B::AGGR must be... :93B::AGGR//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 536 In each occurrence of subsequence B1a2, field :36B::PSTA cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B1a2 if field :36B::PSTA is... Then one occurrence of :36B::PSTA must be... And the other occurrence of :36B::PSTA must be... Repeated :36B::PSTA//FAMT :36B::PSTA//AMOR Not repeated Not applicable Not applicable MT 537 In each occurrence of subsequence B2b, field :36B::PSTA cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B2b if field :36B::PSTA is... Then one occurrence of :36B::PSTA must be... And the other occurrence of :36B::PSTA must be... Repeated :36B::PSTA//FAMT :36B::PSTA//AMOR Not repeated Not applicable Not applicable MTs 540, 541, 542, and 543 In sequence C, field :36B::SETT cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence C if field :36B::SETT is... Then one occurrence of :36B::SETT must be... And the other occurrence of :36B::SETT must be... Repeated :36B::SETT//FAMT :36B::SETT//AMOR Not repeated Not applicable Not applicable MTs 544, 545, 546, and 547 In sequence C, field :36B::ESTT cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence C if field :36B::SETT is... Then one occurrence of :36B::ESTT must be... And the other occurrence of :36B::ESTT must be... Repeated :36B::ESTT//FAMT :36B::ESTT//AMOR Not repeated Not applicable Not applicable MT 548 In sequence. B, field :36B::SETT cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. 22 July

40 FIN Sequence B if field :36B::SETT is... Then one occurrence of :36B::SETT must be... And the other occurrence of :36B::SETT must be... Repeated :36B::SETT//FAMT :36B::SETT//AMOR Not repeated Not applicable Not applicable MT 564 In each occurrence of subsequence B2, field :93B::ELIG cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B2 if field :93B::ELIG is... Repeated Then one occurrence of :93B::ELIG must be... :93B::ELIG//FAMT and DSS must not be present And the other occurrence of :93B::ELIG must be... :93B::ELIG//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 565 In subsequence B2, field :93B::ELIG cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Subsequence B2 if field :93B::ELIG is... Repeated Then one occurrence of :93B::ELIG must be... :93B::ELIG//FAMT and DSS must not be present And the other occurrence of :93B::ELIG must be... :93B::ELIG//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 566 In sequence B, field :93B::ELIG cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence B if field :93B::ELIG is... Repeated Then one occurrence of :93B::ELIG must be... :93B::ELIG//FAMT and DSS must not be present And the other occurrence of :93B::ELIG must be... :93B::ELIG//AMOR and DSS must not be present Not repeated Not applicable Not applicable MT 567 In sequence B, field :36B::STAQ cannot appear more than twice (maximum 2 occurrences). When repeated, one occurrence must have Quantity Type Code FAMT and the other occurrence must have Quantity Type Code AMOR. Sequence B if field :36B::STAQ... Then one occurrence of :36B::STAQ must be... And the other occurrence of :36B::STAQ must be... Repeated :36B::STAQ//FAMT :36B::STAQ//AMOR Not repeated Not applicable Not applicable 40 Error Codes

View more

0 Comments

Leave a Comment