SWIFT МТ103 - Detailed Analysis

[Man]

Annotation​

Lately, there have been too many scammers on the Internet who take advantage of people's illiteracy (lack of knowledge) and rip them off, sometimes quite a lot. If you analyze payments in the SWIFT system, you can especially often see offers for a manual for fine-tuning payments (manual download), which hackers put in (this is how the guys will explain their work to you), as a result, the maximum you will get is a pdf file with an incomprehensible set of characters that looks logical, but has nothing in common with SWIFT. This article will describe the procedures by which you can really compose a payment message that can pass compliance for amounts up to 500 thousand euros, thanks to the trust relationships within the SWIFT system. You will also understand the general principle of the SWIFT system, and will be able to conduct an initial check of messages and identify fakes.

Prologue​

Everything described in this article is provided for review. All data related to companies, actors in the article are summarized, edited or changed. The article does not call for illegal actions. It is provided for review for educational purposes.

Let's get to the point:
Typical hacker attacks related to the SWIFT system that we can see in police reports or in the media are the following:
1. Compromise of the institution's network;
2. Using critical bugs of the payment system;
3. Compromise of the credentials of the SWIFT payment operator;
4. Access to the institution’s SWIFT messaging interface;
5. Authorization of payment messages using compromised payment operator accounts and messaging interface;

To execute this attack vector you would need to compromise multiple users, multiple systems, understand how the target application works, bypass two-factor authentication, then you would need to hide access logs to avoid alerting legitimate operators, configure malware, etc. - which even in the short description sounds VERY complicated.

Therefore, we will go from simple to complex, and describe the structure of the system as a whole, which will help you understand how the SWIFT system works, and analyze a standard payment order, and then more closely study each attack vector separately.

General parameters​

To begin, you need to fully understand and understand the specific "section" of the payment system (SWIFT) at the target institution. We will simply call it SWIFT.

SWIFT accepts data in any format and outputs initial payment instructions in ISO 15022/RJE/SWIFT MT format.

We will focus on the compromise of the MT103 payment order, namely:

• MT - "message type"
• 1 - Category 1 (payments and customer checks)
• 0 - group 0 (transfer of financial institutions)
• 3 - Type 3 (notification)

All together this is classified as MT103 Single Customer Credit Transfer (SCCT)

In addition to the message type, we need to understand how this payment is processed. It is quite typical for these types of transfers and looks like this:

1. The System (SWIFT Application) accepts data from the user in a format convenient for him (for example, by filling in fields in the graphical interface of the application). Then the System outputs the initial payment instruction in SWIFT MT format;
2. The system sends this message further, to a component called the Middleware, which converts (if necessary) the received message into a modern SWIFT format that the system understands. In essence, this is a message broker provided for non-institutional financial institutions.
3. The PPO sends the generated message to the Institutional Financial Institution (Bank, Credit Institution or other, hereinafter referred to as the Bank for convenience) for processing.
4. The bank checks the contents of the message, carries out a number of checks (whether the company is on the black list, whether it is checked by the anti-money laundering system, checks the legality of the transaction in case of high volumes, makes a request to the antimonopoly authority or to the currency control, if such options are available in the country where the bank is located)
5. If the message is formed correctly and passes the internal bank check, the message is sent to Swift Alliance Gateway, where it is signed and sent to the recipient organization/bank via SwiftNet.

Let's dive a little deeper into this technology.

Let's look into the details of data exchange​

Let's ask ourselves: how are these messages transmitted between all these systems?

Most often, in any Payment System, so-called Message Queues (MC) are used to transmit messages between different components.

There are various "adapters" that can be used between systems communicating directly with the Swift Alliance Gateway:

• Remote Host Adapter API (HAPI)
• Message Queuing Host Adapter (MQHA)
• Web Services Host Adapter (WSHA)

From the SWIFT CSP requirements you can see that to maintain a Message Queue you need a dedicated Queue Manager (QM) server that will host the various Message Queues (MT1xx, MT2xx, etc.) from which the systems will send and retrieve messages.

The requirements also strictly stipulate that there must be at least two queue administrators. One manages queues in the SWIFT Work Zone, the second for communication in the corporate network and/or other systems of the institution (for example, intra-bank transactions must be SEPARATED from transactions related to the SWIFT system, as well as transactions in other payment systems, such as VISA, MASTERCARD or SEPA).

We define a viable vector for implementation​

It's time to define the task: "Place the payment order in the queue and successfully process it in all systems (pass validation)"

The task is simple, so let's ask the right questions that will help in implementation:

1. How do I get write access to the desired queue?
2. What protects messages in queues?
3. What protects communication during transit?
4. What format are the messages in?
5. How to compose a syntactically correct message for the chosen format? (goal - 0 errors)
6. Where is PKI (Public Key Infrastructure) located? How, where and when are messages signed and verified?
7. Is there any way to bypass the message signature?
8. What values in messages are dependent/controlled/determined by the system, processed outside my (or another person's) control?
9. What is the maximum amount I can transfer using without alerting the institution/requiring manual verification?

Now let's describe the task itself in more detail, point by point:

1. How to correctly write a payment instruction for 500 thousand euros;
2. Insert this payment instruction into the queue;
3. The message must pass syntax checking (ACK or NACK);
4. The message must pass all additional checks, including AML check;
5. The message must be successfully signed;
6. Pass validation when checking with SWIFTNet rules;

From a hacker's point of view it looks like this:

1. Compromise the institution's network;
2. Gain access to the Queue Manager administrator workstation;
3. Obtain the necessary company details;
4. Carry out the required work.

The following should be avoided:

1. Attack involving the SWIFT payment operator (the system itself);
2. Attack using access to the SWIFT application (direct access to the official banking application);
3. The need to compromise the key signature (forgery of digital keys);
4. Need to compromise SWIFTNet operator accounts or certificates.

Disassembling the body of the MT103​

We need to figure out how to make the simplest payment instruction in MT103 format. As a rule, a bank operator (or any other user/operator of the SWIFT system) writes payment messages just like you and me, but using a convenient graphical interface (for example, Alliance Access). In its raw form, it looks something like this:

:20:TRANSACTIONMT103
:23B:CRED
:32A:200707EUR500000,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:OUR

Let's look at each highlighted field :ТАК:in more detail.

:20: Transaction Link

16x - This field can only be 16 characters long. This link allows your bank to identify the message in its network, just like the sending bank.

:23B: Bank transaction code

4!c — four capital letters responsible for the operation. In our case, it is CRED — beneficiary lending.

:32A: Date / Currency / Amount

6!n3!a15d — the field is filled in strict sequence. First the date (year/month/day), then the currency in capital letters (for example: EUR, USD, RUB), then the amount in random order in numbers.

Also, for example, if the commission in field 71A is indicated as BEN, then field 33B is added, where the exact amount to be credited to the account will be indicated.

:50K: Client

This field contains the details of the orderer (legal entity, individual, bank). The field is used in MT103, MT103+ messages with options "A", "K", "F". Depending on the option, the filling varies from bank to bank.

:59: Beneficiary

This field specifies the details of the beneficiary client in whose favor the payment is made:

- the client's account number in the beneficiary's bank (When transferring funds in favor of clients of banks in countries that support the EU Directive on mandatory indication of IBAN, indication of the account number in IBAN format is mandatory. (indicated without any separating characters)
- name of the client;
- address (if available);
- city, country.

:70: Money Transfer Information

This field, 4 lines of 35 characters each, contains information about the transfer, including: the purpose of the transfer (payment for a contract/training/travel voucher, financial assistance, etc.), the number and date of the contract, sales documents, the name of the work performed/services rendered, goods, etc.

:71A: Commission details

It is indicated at whose expense the commissions for the transfer are paid. In this case, one of the possible options is noted:

- OUR - the total amount of fees charged by the Client Bank, as well as fees of other banks participating in the payment, are paid by the client-payer (field 50A, K or F).

However, there is a possibility that the funds will not be credited to the beneficiary in full.

- SHA - the total amount of fees charged by the Client Bank is paid by the client-payer (field 50A, K or F), and fees of other banks participating in the payment are charged from the transfer amount;

- BEN - the total amount of fees charged by the Client Bank, as well as fees of other banks participating in the payment, are charged from the transfer amount specified in field 33B.

Now that we have a valid message body, if we had access to the SWIFT Alliance Access operator, we could paste this message into the raw message creation interface and make the transfer. The only thing left to do is add the BIC codes of the sender and recipient, and select the bank divisions from and to.

But it is not enough to study the body of the message itself (you must remember that all fields must be filled in STRICTLY according to the instructions, which is what most scammers who draw you payment orders are guilty of, violating the basic rules for filling out documents). Therefore, let's move on to the next part and analyze the message as a whole, not just its body.

Detailed analysis of MT103​

As mentioned above, we have only looked at the body of the message, which is "Block #4" (called the "Text Block") in the SWIFT MT message standard. As the name suggests, you can guess that there are also blocks 1-3, and you would be right.

Typically, these blocks are generated automatically by payment processing applications (such as SWIFT Alliance Access), and are not necessarily entered by operators.

The "complete" MT103 message consists of 6 blocks:

• Block 1 – Basic Heading ;
• Block 2 – Application Title ;
• Block 3 – Custom Title ;
• Block 4 – Text block ;
• Block 5 – Message tail ;
• Block 6 – System block .

BLOCK 1 (Base Heading)​

According to SWIFT documentation, the basic header looks like this.

{1:F01EBNKGB20AXXX0000999999}

Let's break it down into its component parts

{1:F01EBNKGB20AXXX0000999999}

This is the block's serial number (cannot be 2, 3 or any other in this block).

{1:F01EBNKGB20AXXX0000999999}

This is the application type, in our case it is F - i.e. FIN

{1:F01EBNKGB20AXXX0000999999}

This is the message type, in our case it is 01. Which is equivalent to FIN, i.e. it is not a response message - like ACK or NACK.

{1:F01EBNKGB20AXXX0000999999}

This is the sender's BIC EBNKGB20, where EBNK (Bank Code) GB (Country Code) 20 (Territory Code).

{1:F01EBNKGB20AXXX0000999999}

This is the sender's terminal number. Usually it is A, but in the case of a huge institutional bank there may be other terminals.

{1:F01EBNKGB20AXXX0000999999}

This is the sender's branch. If it is not necessary to indicate the bank branch, then simply fill in XXX.

{1:F01EBNKGB20AXXX0000999999}

This is the session number, in our case it is 0000

{1:F01EBNKGB20AXXX0000999999}

This is the message sequence number, in our case 999999

Looking ahead, it became clear the first problem that a hacker will encounter: this is the session number and the serial number of the message, it is quite difficult to guess the exact values that will not stand out from the general outline of messages sent in automatic mode.

BLOCK 2 (APPENDIX TITLE)​

Also from the documentation, you can easily understand that it looks like this:

{2:I103FBNKFR20XXXXN}

Let's break it down into its component parts:

{2:I103FBNKFR20XXXXN}

This is the block serial number, there can only be 2.

{2:I103FBNKFR20XXXXN}

This is the message identifier. In our case, it is I (Input), but there is also an Output or O option. It is important not to make a mistake here, Input - despite the fact that it begins with IN - is an outgoing message, and Output is an incoming message. Here, designers often make a mistake, issuing it with the value O.

{2:I103FBNKFR20XXXXN}

This is the message type, in our case it is 103, or a credit transfer for one client.

{2:I103FBNKFR20XXXXN}

This is the customer's bank identifier, FBNKFR20, where FBNK (Bank Code) FR (Country Code) 20 (Territory Code).

{2:I103FBNKFR20XXXXN}

Next comes X — or the number of the recipient bank's terminal. Usually all non-specialized terminals are marked with X. And this gives another mistake in SWIFTs, artists. Usually they write only three X, when there were always 4.

{2:I103FBNKFR20XXXXN}

This is the branch of the recipient bank. For regular transfers, the branch is usually not required to be specified. Unlike, for example, transfers of Bank instruments.

{2:I103FBNKFR20XXXXN}

This is the priority of the message. In our case, it is N (Normal), meaning not urgent. It can also be U (Urgent), or urgent. Usually, additional fees of up to $100 are paid for such messages.

BLOCK 3 (Custom Header)​

The third block is used to define some "special" rules for processing SWIFT messages. Using this header, you can specify that messages should be processed using the so-called "Straight Through Processing" (STP) rules, which explain that the message goes end-to-end without human intervention (for example, you sent money from online banking, and it was processed automatically by the computer, without the participation of a bank officer). This can be specified as follows.

{3:{119:STP}}

However, in this form the header will not be valid, because since November 2018 this header now requires a MANDATORY value “Unique end-to-end transsation reference” or UETR, which was introduced as part of Swift Global Payments Innovation (GPI), and since November 2020 absolutely all SWIFT MT1xx, 2xx - must be processed according to the GPI directive in all banks without exception. (This is another reason not to believe the fairy tales of people looking for specific GPI “acceptances”. All SWIFT now work with this protocol.)

The UETR code is essentially a Globally Unique Identifier (GUID) corresponding to the fourth version of the generation algorithm used by the IETF standard “RFC4122”. It consists of 32 hexadecimal characters, divided into 5 parts by hyphens as follows:

XXXXXXXXXXXX-4xxx-Yxxx-ХХХХХХХХХХХХ

Where:

• X – any lowercase hexadecimal character (0 to f)
• 4 – fixed value;
• Y – either 8, 9, a, b.

This value is actually generateable, with an acceptable generated UETR our third block would look like this:

{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}

Where:

{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}

This is the block serial number, there can only be 3.

{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}

This is the message check type, in our case 119, which specifies how to process FIN messages.

{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}

This is the verification area, in our case STP. SWIFT request to verify the message using the Straight-Through Processing principle.

{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}

Points to the UETR field.

{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}

The UETR value itself.

BLOCK 5 and 6 (TAIL and SYSTEM BLOCK)​

We have already discussed the "Message Body" or BLOCK 4 earlier, so we will skip it and look at the last two blocks.

Before we move on, let me explain a little about the pointlessly complicated concept of SWIFT messages.

- Input message is a message that is SENT from an institution, as this message is “entered” by the operator and sent by the institution to another institution.

- Output message – this is the message that “enters” the institution. So this is the message that is output by SWIFTNet and received by the institution.

For input messages these blocks are not a problem because the headers are only used to indicate whether the message was intended for training/testing or whether it is a possible duplicate (copy of the message):

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

Where TNG stands for TRAINING and SPD stands for Possible Duplicate.

However, for output messages, things are a bit more complicated, and the system block might look like this:

{5:{MAC:13461AEF}{CHK:4A3367FD3D76}{TNG:}}{S:{SPD:}{SAC:}{COP} {MDG:5E87F8F390E5FB886E8311E4D7C994371FA9AF3119B2C314DAE4583 8AFF08AC}}

Breaking down these values we get the following.

Tail ({5:})

MAC – a message authentication code calculated based on the entire contents of the message using a secret key received from the recipient's bank and a secret algorithm;

CHK is a PKI checksum of the message used to ensure that the message has not been corrupted in transit.

TNG – a flag indicating whether this message is a test or training message.

System unit ({S

SPD - possible duplicate

SAC – a mark of successful certification and authorization, it is present only in cases where the signature verification was successful or the authorization and verification of RMA (Application Management) was completed urgently.

COP – indicates that this is the primary copy of the message;

MDG – HMAC256 messages using LAU keys

And if you understand the logic, then specifying the same MAC or CHK in SWIFT sending is impossible. Since only the receiving bank can give them to you and print them, the sending bank cannot know these values.

Having dealt with the logic of the SWIFT message, let's move directly to sending messages.

Hacker training logic​

Since earlier we analyzed this from the point of view that SWIFT type Manual Download, or other types are installed on us by hackers, or bank officers, we must understand their logic.

Let me remind you that the goal is to insert our message into the queue so that it passes all the validators and gets into SWIFT NET.

To queue our message we will need two things:

1. Access to the correct queue manager (QM);
2. Possibility of recording in this MO.

Depending on the bank/financial organization, access to MO can be obtained in different ways, sometimes very complex. However, if we try to get access "from scratch", the scheme will look something like this:

1. The MO administrator gains access to his dedicated workstation using the AP data;
2. We get remote access to a dedicated server via RDP, since only the administrator's computer is on the white list of those who have access to the server.
3. An additional step may be required if queues use Channel Authentication Records, allowing only certain systems or user accounts to access a particular message queue.
4. May require an additional step if the channels are additionally protected by Message Encryption (MQME), which encrypts messages based on the channel they came from. So, even if you are the Chief Administrator of the entire Bank, you can only read/write to the queues specifically allocated to you, specified in the MQME configuration file.
5. Based on the input, we conclude that the MO administrator can use additional tools, such as Jump Server, to read/write to the desired message queues.

So in this scenario, to gain access to the message queues, the attacker would have to compromise the MO admin's AP account and workstations, then use them to gain access to the jump host, from where he can then access the message queue, provided he knows the correct channel name, has authorization configured to access it... and maybe throw some MFA in there.

When discussing such complex attacks on financial market infrastructure (FMI) in this article, it is more reasonable to accept that Advanced Persistent Threat (APT) will be considered as a feasible task. Therefore, let us consider a real attack vector on the Bank.

Viable attack vector​

Armed with the idea of how to gain access, understanding all the technologies and security controls, we will move on to a detailed analysis of attack vectors.

It is important to add that between the Swift Alliance Gateway adapters and the Bank (or other institutional financial institution (IFI), there are LAU (local authentication) channels, just like between the Bank and the middleware (intermediate software, such as Alliance Access). It is probably worth explaining what LAU is.

“Local Authentication” or LAU is a security control implemented by SWIFT to authenticate a message using a pair of shared keys between the two systems. These keys are combined and used to generate a SHA256 HMAC of the message and add it to the S block (which we talked about earlier). These keys can then be checked and validated by the recipient system. In effect, this is a check of the authenticity and origin of the message. So even if an attacker sends a fraudulent payment from a fictitious terminal, they would first need to compromise the left and right LAU signing keys, or generate the correct HMAC and add it to the message, for it to be accepted and processed successfully. (Which again makes liars who say they are spoofing a bank server nothing more than liars).

But let's leave LAU aside for now, first we need to decide what our goal will be. After all, in essence, there are a lot of queues inside the bank, and each of them has "incoming" and "outgoing" queues. Keeping this point in mind, it is worth noting: the incoming message must be in the format expected by the target system (everything depends on the specific outgoing system), and the outgoing message - in the format that will be accepted and processed, in accordance with the rules. Therefore, let's go from the end.

Purpose of SWIFT ALLIANCE GATEWAY

In my opinion, this is the least feasible attack vector. To do it, a hacker would have to figure out how SWIFT adapters work (not sold freely), explore every corner of the system, which is unlikely.

SWIFT's implementation of LAU on messages between adapters is a great way to secure the communication channel. Which eliminates the possibility of an attack in this direction.

Note: On the Internet you probably came across manual download, and ledger 2 ledger. So, this is the very thin place where you can conduct this message. Even thousands of Chinese hackers cannot do this.

Purpose of the BANK

Let's put aside LAU and SWIFT adapters for now, remember the sessions and message numbers at the beginning of the article? Well, they are inserted by the bank, at the very end of the message's life path. Given the fact that we do not know how to generate these values without gaining access to the bank's entire infrastructure, as well as to the encrypted data on their servers, it does not seem possible to consider the Bank as a target at this point.

Purpose Software (PSO)

In order for the PPO to become your target, you need to enter a message into the Bank's "incoming" queue, or the PPO's outgoing queue. In essence, it must match the format of messages that the PPO issues. After the PPO sends a message to the Bank's queue, in theory, we will add both the session number and the sequence number to the message, along with the UETR code. This is an extremely interesting attack vector.

However, the PSU is most often a "partner" of the SWIFT system, and they usually provide partners with a cloud solution developed using the Alliance Access Development Kit, which allows vendors to develop software compatible with SWIFTNet and actually implement the LAU. So, to forge a message here means to compromise the left and right signature keys of the LAU, manually calculate and write the HMAC of the message (without errors), and then place it in the queue.

Purpose of the Bank Payment System (PS)

As we described earlier in this article, the incoming data is an “application-specific” payment instruction from the target institution’s back-office system, but it is not the SWIFT message itself. And that’s a very interesting concept.

What about outgoing queues?

Despite the fact that PS receives data in a custom format, the outgoing message vaguely resembles SWIFT MT. Which would be an ideal attack vector for a hacker. In addition, PS does not have a LAU between it and the PPO, because, unlike the PPO, PS is not a SWIFT partner in the area of sending messages. It is just one of a few payment systems within the Bank.

Furthermore, since the PS is essentially just a small part of a much larger back office architecture, it is not part of the SWIFT Secure Zone, and therefore uses the Queue Manager in the more accessible section of the network (MO1).

Given all of the above, and having a compromised MO administrator account, we could use access to the corporate network to authenticate MO1. Also, the hacker could subsequently record the payment order in the "outgoing queue" of the payment system.

Let's formulate what we want:

In theory, why this should work is that the middleware is an application that implicitly trusts everything it receives from the relevant upstream systems. This is intentional, since by design of the security model, a message to send funds can be created at any point in time. If there is a system in place that aims to ensure that a payment message is valid at any point upstream, then downstream systems should have no problem processing those messages (with some exceptions). Without this design, at the very least, it is impossible to maintain a high-performance payment system.

The plan is as follows:

• use MO administrator access;
• abuse the "trust relationship" between PS, PPO and the Bank
• enter the payment message into the outgoing queue of the PS;
• payment order MT103 must pass all validators.

Hacker initiates payment​

Having understood a little about how the system works, we check the elements that are needed to send SWIFT.

• Whole system;
• Message format;
• Queue Manager;
• Required queue;
• Write, read, and administrator access rights;
• Access to SWIFT message exchange;
• Fake message.

Now, the hacker needs to create a valid payment message using the real details of the company in the target institution. By the way, this was the reason, earlier, when looking for companies and their details in the form of CIS - on the Internet. Most people need donors for their transfers. In our article, these data will be fake for the sake of the article. I.e. these are not real details.

Sender's account details are John Doe, GB12EBNK98765412345678 on EBNKG20;

Beneficiary account details: Alise Smith, GB15EBNK9876587654321 on EBNKG20;

You may have noticed that the sender and receiver have identical BIC. This is done in the article because our hacker wants to see how the message is processed by SWIFTNet, and was able to analyze it from start to finish. Moreover, we use the BIC code for "test&training".

Note: A SWIFT message may be from one bank, sent to the same bank, and processed by the SWIFTNet system, not within the bank.

Now, with access to these "real account audits" and the knowledge you have from reading the article, we generate the MT103 outgoing message:

{1:F01EBNKG20AXXX0000000000}
{2:I103EBNKG20XXXXN}
{3:{119:STP}{121:3b02c40e-e060-400a-ac74-47e006dd26e3}}
{4:
:20:SWIFTMT103FAKE
:23B:CRED
:32A:220214EUR500000
:33B:EUR500000
:50K:/GB12EBNK98765412345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59: /GB15EBNK98765487654321
ALICE SMITH
ALICE'S COMPANY
ALICE'S COMPANY
10 ALICE STREET< MACHESTER, GB
:70AYMENT-TEST
:71A:SGA
-}{5:{TNG:}}{S:{SPD:}}

Note: Field 33B is optional, however the MT standard states that "if the sender and recipient country code belong to the same country, then field 33B is mandatory". Therefore, if 33B is missing, the network validation rules will fail, SWIFTNet will return NAK with error code: D49

Let's put the mandatory and optional fields aside for now. We need to adjust our message so that it can be eaten by the outgoing queue of the Bank's Payment System.

First, we will mark the first three blocks on one line. Next, we will remove field 121 (UETR) from the user header, as this field will be generated by the bank immediately before sending to SWIFTNet.

Next, in the TRN field, we check that there are exactly 16 characters, so as not to make a classic mistake.

Don't forget to add a decimal point in the transaction amount. Otherwise, the syntax check rules will be violated and the message will not pass the SWIFTNet check.

We make sure that the IBANs are accurate, otherwise the message will not be able to understand what type of signature to use in the SWIFT network. In our article, the IBANs are fake and they are not broken, but hackers must use legitimate data in their work.

All that remains for us to do is to delete the trailer block (5) — since it will also be added to the BANK. We delete the system block for the same reason.

Our final message looked like this:

{1:F01EBNKGB20AXXX0000000000}{2:I103EBNKGB20XXXXN}{3:
{119:STP}}{4:
:20:MYSWIFTMT103FAKE
:23B:CRED
:32A:220214EUR500000,00
:33B:EUR5000000,00
:50K:/GB12EBNK98765412345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREE, LONDON, GB
:59:/GB15EBNK98765487654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MACHESTER, GB
:70AYMENT-TEST
:71A:SHA
-}

If you look closely at the end result, many of the problems we thought about have faded into the background. The deeper we delved into the SWIFT jungle, the easier it became to compose a message.

Now we have a raw message in MT103 format, so we save it to a file - for example, 103.txt, why not, and add it to the message queue.

• Using access to the queue manager account, we connect to his computer;
• Let's go to the server;
• Opens our tools for working with managers, login in the queue manager, at the moment of the outgoing queue of the Payment System;
• We connect to the queue;
• We select our file 103.txt;
• We call the "write to queue" function;
• And... the operation is completed.

Now you need to go to Alliance Access. Open the message history tab, and wait 15-20 minutes for it to process.

ACK. It works. (Note: in reality, of course, it is unlikely to work the first time. When I was just learning SWIFT, all my attempts were NAK, and those same corrections in the text of the message are just the result of practice in composing messages, and searching for errors in these messages, so as not to be noticed by a legitimate operator)

With such a payment order we will be able to process the message within the bank. But this is not the same as sending a message to another bank.

And here many other moments emerge, where one MT103 registration is not enough. 103, only a payment notification, but with it the money does not necessarily fall into the account (this is possible only with direct correspondent relations between banks). Moreover, the chance to do this somehow legally dramatically decreases, because the message will be checked by intermediary banks. Therefore, we dig further.

Let's figure out where we lost money​

So, we sent MT103 and it even reached the target institution. But where is the money? Everything is quite ambiguous here, because in order for the money to be credited, it must be written off from somewhere. But first things first.

First, let's figure out how the process of writing off money inside a bank generally occurs. For example, we have client A and client B in Deutsche Bank (hereinafter DB). I (Client A) want to send 10 euros to my friend (Client B). I just need to inform the bank of my intentions, and the bank will write off 10 euros from my account and credit this money to my friend's account. In essence, the procedure is carried out within the Bank's Payment System, inside the bank itself. The money does not enter the bank or leave it, it is simply recorded in the internal accounting and everything is balanced.

But what if Client B is at another bank, say HSBC. It would be easy for DB to debit 10 euros from my account, but how would our bank be sure that HSBC credited Client B's account with 10 euros? Why would HSBC agree to owe Client B more than they did before? In essence, they would agree to such a transaction in order to owe someone more, if they ultimately owe someone a little less.

That other one, to whom they owe less, cannot be Client A, because we are not connected to their bank in any way, and do not even have accounts in HSBC. In that case, can they contact each other banks? For example, DB will open its account in HSBC, and HSBC will open its account in DB.

Then the diagram will look like this:

• DB debits 10 euros from Client A's account;
• DB adds 10 euros to the HSBC account opened with DB;
• DB notifies HSBC that they have received 10 euros in their account and they want to transfer these 10 euros to Client B;
• HSBC, knowing that their deposit in DB has increased by 10 euros, can top up the account of client B with this money.

Now DB, instead of owing Client A, owes HSBC. HSBC, which had a zero balance, now owes 10 euros to Client B, and DB owes them the same 10 euros.

This payment processing model is the activity of banks based on correspondent relations. We have analyzed only the simplest scheme, with banks directly connected to each other. But sometimes, in order to lay out a route for a payment, it is necessary to use a third or even fourth bank in the chain until the payment reaches the Beneficiary. Which certainly increases the costs and complexity of making such a payment.

The bank is also concerned about the fact that this is a very risky type of payment. Let's see how it looks from the bank's side. After all, as a result of this payment, the bank becomes vulnerable to DB. In our case, it is only 10 euros. But let's imagine that the amount is not 10 euros, but, for example, 100 million. And the correspondent bank is not DB, but a smaller, more reliable operator. In this case, HSBC will have big difficulties if the small bank goes bankrupt. In this case, of course, you can ask not to credit the money to the HSBC account in DB, but ask HSBC to write off the money from the DB account in HSBC. But in this case, other problems arise, inherent in the movement of large funds.

It is also worth considering that the SWIFT network costs money. If DB needs to send a message on the SWIFT network for each transfer to the account of client B - 10 euros. Then soon the number of expenses in the statement will increase many times over. And the worst thing is that there is a liquidity problem. Imagine how much money DB would need to have in the accounts of correspondent banks, in case any of the clients wanted to transfer money to HSBC, or Lloyds, or Citi, or any other bank. The same money can be invested in assets, issued a loan, spent or launched into trading, where it will bring income to the bank.

That is why banks do things a little differently. Most banks track all the numerous payments and record the difference in their calculations at the close of the banking day. With this approach, each bank does not need to have huge amounts on the account of other correspondent banks, and this money can be used more effectively. In particular, it reduces the banks' costs and allows not to keep a huge amount of money frozen on the correspondent accounts of other banks.

But even with this approach, there are threats - loss of completeness of the calculation. You can send a payment early in the morning, but the beneficiary bank will not receive the money until a certain moment. After all, at any moment of the day, before the completion of the calculation, the sender may go bankrupt during the transfer: crediting funds to the recipient's account by the receiving party is a rash move. And this means a delay.

But you can of course take the risk and cancel the transaction in case of problems, then the payment will never be considered complete, and the recipient cannot count on this money until a certain moment.

And yet, how is consensus and zero risk for the counterparty achieved?

After all, none of the approaches described earlier can be applied and be absolutely sure that the payment will be made quickly, it cannot be cancelled and the sending bank will not go bankrupt later. You need a guarantee of this kind, but alas, no one will give you a guarantee for 100 million euros in bonds or shares if there is a risk that these 100 million will not be paid, or they cannot be returned.

Here the Central Bank system will help us. This is what systems such as CHAPS, FedWire, Target 2 were created for, which deal with transfers of pounds, dollars and euros respectively. These systems carry out the movement of funds in real time between accounts that banks have in the corresponding Central Bank ( i.e. all the largest banks in the country have an account in the Central Bank, where they can transfer money from one bank to another, simply by giving instructions to the Central Bank to write off funds from one account and credit them to another ). In essence, this is a system of gross settlements in real time ( Note: no accounting of debts, i.e. instant, complete, without the possibility of returning funds ).

And only now, we will talk about Mt202 coverage. When sending SWOFT for a small amount, the recipient bank checks the replenishment of its account for the specified amount in the sender's correspondent bank, if the recipient's bank account is not replenished, it writes off these funds from the sender's bank account in its bank, and credits the payment further along the chain. The write-off from the account will be displayed in the statement of the sender's bank, thereby showing that the funds have gone to the beneficiary. In the absence of a balance, or lack of liquidity in this account, the account can be closed, and in the case of Central Banks, it also threatens to revoke the license due to the very notorious liquidity that will reveal the fraudulent scheme and the hacker who made the transfer.

Which leads to a simple conclusion. Money in correspondent accounts is not in large quantities. Even in large banks, the size of these accounts rarely exceeds 50 million euros. Billions are out of the question. Because the bank does not need money lying dead weight. In addition to this, the Central Bank system uses SWIFT only for notification purposes, and all transfers in amounts larger than 15 million euros undergo additional clearing. Which for dreamers with 50 million per tranche is like a knife in the back.

A little bit about real hackers​

And yet, hacks of SWIFT systems did happen. More precisely, small banks and their corporate networks were hacked. But hacks did happen. And attempts to send SWIFT too. Despite the fact that a hacker has many other methods to help withdraw huge capital in a short period of time, with such a level of access.

But we will finally look at what things hackers have to do to ensure that your payment is successfully processed and reaches the beneficiary automatically.

Hypothetically, a hacker can own an account with funds in the required bank. Then an MT103 payment order is enough. A legitimate operator will see and process the payment in 100% of cases. It will write off money from your correspondent account and send it further through banking channels. But in most cases, by gaining access to the banking infrastructure, you do not gain access to companies and their money, which means that hackers will have to operate with money in the correspondent account.

And here you will have to resort to all sorts of tricks. Fake legitimate programs by sewing a backdoor into them, printer queues, forge and intercept mail on the bank's mail servers, and so on. This is very long, painstaking and expensive work, with no room for error. No one needs ordinary people from the Internet who want to keep their pockets wider for free, so that someone will give them money, and they will then win back from this money to you - no one needs them.

In 99% of cases, all this works through pre-established channels, with people known to each other, and getting into these circles from the outside simply by possessing and fluttering beautiful eyes will not work.

Afterword​

Bottom line. Working in the SWIFT topic is long, painstaking, and very expensive. It is associated with high risks and the possibility of going to jail. Therefore, it is highly recommended to avoid this type of activity. In most cases, you will most likely get caught in a scam, and even if you do not get caught, then after work there is a high chance that your "techie", not much of a professional, and in less than a couple of days, citizens in uniform will come to you with an arrest warrant. The money will of course be recalled, and withdrawing it from the account, or further movement - this will be an aggravating factor in your future business.

And this is not a horror story to scare, but real life cases that happen every year. There are very few successful operations to withdraw funds. And they are carried out in very narrow circles, by people known to all bankers. Perhaps you even know them, since you are reading this article.

Most people are looking for a simple, free, reliable channel to send money to their accounts, and for it to happen tomorrow. It never was, and never will be. Only in fairy tales.

Peace to all. Work with professionals, make money, and don't waste air on the Internet.