SWIFT MT103 - Detailed disassembly

[Lord777]

Abstract

In recent years, on the Internet there are too many scammers who take advantage of people's illiteracy (lack of knowledge) and trick them for money, sometimes not small. If you disassemble payments in the SWIFT system, you can often see sentences about manual download, which are put by hackers (the guys will explain you their work), you will receive a pdf file with an incomprehensible set of characters, which looks logical, but has nothing to do with SWIFT. In this article will be described the procedures, due to which you will be able to create a payment message that may be compliant up to 500 thousand euros, due to the trust relationship within the SWIFT system. You will also understand the general principle of SWIFT system operation and be able to perform initial message checking and detection of falsifications.

Prologue

Everything described in this article is presented for information purposes only. All data related to the companies, actors in the article is summarized, edited or changed. The article does not call for illegal actions. This article is for educational purposes.

Let's get to the point:

Typical attacks by hackers related to the SWIFT system that we can see in police or media reports are as follows:
1. Compromise of the institution's network;
2. Use of critical bugs of the payment system;
3. SWIFT payment processor credentials compromised;
4. Access to the institution's SWIFT messaging interface;
5. Authorization of payment messages using compromised payment operator accounts and messaging interface;

To perform this attack vector you will need to compromise multiple users, multiple systems, understand how the target application works, bypass two-factor authentication, then you must hide access logs to avoid warnings from legitimate operators, configure malware, etc. - which even in a brief description looks VERY complicated.

So we'll go from the simple to the complex, and describe the whole system setup to help you understand how SWIFT works, and take apart a standard payment order, and then take a closer look at each attack vector individually.

General parameters
First, you need to fully understand and deal with the specific "section" of the payment system (SWIFT) in the target institution. We will call it simply SWIFT.

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

We will focus on the MT103 payment instruction compromise, viz:

• MT - "message type"
• 1 - category 1 (payments and customer cheques)
• 0 - Group 0 (transfer of financial institutions)
• 3 - Type 3 (notification)

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

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

1. The System (SWIFT Application) accepts data from the user in a convenient format (e.g. by filling in the fields in the graphical interface of the application). The System then 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. This is essentially a message broker provided to non-institutional financial institutions.
3. The SRP 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 content of the message, makes a number of checks (the company is not on the black list, undergoes anti-money laundering checks, checks the legality of the operation in case of high volumes, makes an inquiry to the antimonopoly body or the currency control, if such options exist in the country where the Bank is located)
5. If the message is generated correctly, passes intra-bank verification, the message is sent to the Swift Alliance Gateway, where it is signed and sent to the recipient organization/bank via SwiftNet.

Let's delve a little deeper into this technology.

Understanding the details of data exchange
Let's ask a question: how are these messages transferred between all these systems?

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

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

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

You may know from the SWIFT CSP requirements that in order to maintain a Message Queue you need a dedicated Queue Manager (MO) server which will host the various Message Queues (MT1xxx, MT2xxx, etc.) from which the systems will send and retrieve messages.

Also, the requirements strictly state that there must be a minimum of two queue administrators. One manages the queues in the SWIFT Area of Operation, the other for communication in the corporate network and/or other systems of the institution (for example, intra-bank transactions must be DIFFERENT from SWIFT-related transactions and transactions in other payment systems, such as VISA, MASTERCARD or SEPA).

Identifying a viable vector for implementation
It's time to decide on the task: "Place a payment order in the queue and process it successfully 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 access to an appointment in the right queue?
2. What protects messages in queues?
3. What protects the message in transit?
4. What format are the messages in?
5. How to compose a syntactically correct message for the selected format? (target - 0 errors)
6. Where is the PKI (Public Key Infrastructure)? How, where and when are messages signed and verified?
7. Is there any way around the message signature?
8. What values in the messages depend / are controlled / determined by the system, handle them outside of my (or another person's) control?
9. What is the maximum amount I can transfer with help without alerting the institution / requiring manual verification?

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

1. Competently write a payment instruction for 500 thousand EUR;
2. Insert this payment instruction into the queue;
3. The message must pass the syntax check (ACK or NACK);
4. The message must pass all additional checks, including AML check;
5. The message must be successfully signed;
6. Pass the validation when checked by 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. An attack involving the SWIFT payment operator (the system itself);
2. An attack using access to the SWIFT application (direct access to the official banking application);
3. The need to compromise key signatures (digital key forgery);
4. The need to compromise SWIFTNet operator accounts or certificates.

We need to figure out how to make a simple payment instruction in MT103 format. As a rule, a bank operator (or any other SWIFT user/operator) writes payment messages just like you and me, but using a convenient graphical interface (e.g. Alliance Access). In raw form it looks 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 break down each field highlighted :TAK: in more detail.

:20: Transaction reference

16x - this field can be only 16 characters in size. By this link, your bank can identify the message in its network, exactly the same as the sending bank.

:23B: Bank operation code

4!c are the four capital letters responsible for the transaction. In our case it is CRED - crediting the beneficiary.

:32A: Date / Currency / Amount

6!n3!a15d - the field is filled in strict order. First date (year/month/day), then in capital letters currency (for example: EUR, USD, RUB), then in any order of figures the sum.

Also, for example, if the commission in the field 71A - will be specified as BEN, in this case field 33B will be added, where the exact sum to be credited to the account will be specified.

50K: Customer.

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

:59: Beneficiary

In this field the details of the beneficiary customer in whose favour the payment is made are indicated:
- customer account number in the beneficiary bank (When transferring funds in favour of customers of banks of countries supporting the EU Directive on mandatory IBAN indication, indication of account number in IBAN format is mandatory.(indicated without any separating characters)
- Name of client;
- address (if any);
- city, country.

:70: Remittance information

This field is 4 lines of 35 characters each - information about the transfer, including: purpose of the transfer (payment for contract/training/voucher, material assistance, etc.), number and date of the contract, goods documents, names of works executed/ services rendered, goods, etc.

Details of commission

Details of payments of commissions when effecting a transfer shall be indicated. One of possible variants is marked:

- OUR - total amount of commissions charged by the Bank-Client, as well as commissions of other banks, involved in the payment process, shall be paid by the paying customer (field 50A,K or F).

in this case there is a possibility of crediting funds to the beneficiary not in full amount.

- SHA - total amount of bank-customer charges shall be paid by paying customer (field 50A,K or F), and charges of other banks, participating in payment processing, shall be charged from transfer amount;

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

Now having a valid message body, if we had access to the SWIFT Alliance Access operator, we could insert this message into the raw message creation interface and make the transfer. It's just a matter of adding sender and receiver BIC codes, and selecting the bank branches from and to.

But it is not enough to study the body of the message (you have to remember that all fields must be filled STRICTLY instructions in what most of the scammers who draw you a payment, violating the elementary rules of filling out documents). So let's move on to the next part and look at the message as a whole, not just the body.

Detailed disassembly of MT103
As mentioned above, we have only dealt with the message body, which is "Block 4" (referred to as the "Text Block") in the SWIFT MT message standard. As the name implies, 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 (the same SWIFT Alliance Access), and are not necessarily entered by operators.

A "complete" MT103 message consists of 6 blocks:

• Block 1 - Basic header;
• Block 2 - Application Title;
• Block 3 - Custom header;
• Block 4 - Text Block;
• Block 5 - The tail of the message;
• Unit 6 - System unit.

BLOCK 1 (Basic Title)
According to SWIFT documentation, the basic header has the following form.

{1:F01EBNKGB20AXXX0000999999}

Let's break it down into its component parts

{1:F01EBNKGB20AXXX0000999999}

This is the sequence number of the block (cannot be 2, 3 or any other number in this block).

{1:F01EBNKGB20AXXX0000999999}

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

{1:F01EBNKGB20AXXX0000999999}

This is message type, in our case it is 01. Which is equivariant 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 (Area Code).

{1:F01EBNKGB20AXXX0000999999}

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

{1:F01EBNKGB20AXXX0000999999}

This is the sender's branch. In case the bank branch is not required to be indicated, just XXX is to be filled in.

{1:F01EBNKGB20AXXX0000999999}

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

{1:F01EBNKGB20AXXX0000999999}

This is the sequence number of the message, in our case 999999

Looking ahead, we saw the first problem that the hacker would face: this is the session number and message sequence number, it is difficult to calculate the right values that will not be blown out of proportion with the messages sent, in an automated mode.

BLOCK 2 (APPLICATION HEADER)
Also from the documentation, you can freely understand that it looks like this:

{2:I103FBNKFR20XXXXN}

Let's break it down into its component parts:

{2:I103FBNKFR20XXXXN}

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

{2:I103FBNKFR20XXXXN}

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

{2:I103FBNKFR20XXXXN}

This is the type of message, in our case it is 103, or a single customer credit transfer.

{2:I103FBNKFR20XXXXN}

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

{2:I103FBNKFR20XXXXN}

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

{2:I103FBNKFR20XXXXN}

This is the branch of the beneficiary bank. For ordinary transfers, the branch is usually not required to be specified. Unlike, for example, Bank Instrument transfers.

{2:I103FBNKFR20XXXXN}

This is the priority of the message. In our case it is N (Normal), i.e. not urgent. It can also be U (Urgent), or urgent. Usually there is an additional fee of up to $100 for these.

BLOCK 3 (Custom Header)
The third block is used to define some "special" SWIFT message processing rules. Using this header you can specify that messages should be processed using so-called "Straight Through Processing" (STP) rules, which clarify that the message goes end-to-end without human intervention (e.g. you send money from online banking and it is processed automatically by the computer, without any bank officer). This can be specified as follows.

{3:{119:STP}}

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

The UETR code, at its core, is a Globally Unique Identifier (or GUID) corresponding to the fourth version of the generation algorithm used by the IETF standard "RFC4122". It consists of 32 hexadecimal characters separated into 5 parts by hyphens as follows:

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

Where:

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

This value is realistic to generate, with an acceptable generated UETR our third block would look like this:

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

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

This is the sequence number of the block, it can only be 3.

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

This is the message validation type, in this case 119, which specifies how the FIN message will be processed.

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

This is the scope of verification, in our case it is STP. SWIFT request to verify the message according to the principle of Through Processing.

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

Indicates the UETR field.

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

UETR value itself.

BLOCK 5 and 6 (TAIL and SYSTEM BLOCK)
Earlier we already discussed "Message Body" or BLOCK 4, so we skip it and consider the last two blocks.

Before we move on, let me talk a bit about the pointlessly complex concept of messages in SWIFT.

- An Input message is a message that is SEND from an institution, as this message is "entered" by the operator and sent by the institution to another institution.

- The Output message is the message that is "entered" by the institution. So this message 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 the output messages, things are a bit more complicated and the system block may 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 is a message authentication code calculated based on the entire contents of the message using the secret key that has been obtained from the recipient bank and the secret algorithm;

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

TNG is a mark indicating whether the message is a test or a training message.

System unit ({S

SPD - possible duplicate

SAC - indicates successful authentication and authorization, this is only present if the signature verification succeeded or if RMA (Application Management) authorization and verification was rushed.

COP - indicates that this is the master copy of the message;

MDG - HMAC256 message using LAU keys

And if you understand the logic, specifying the same MAC, or CHK in the SWIFT send - is not possible. Only receiving bank can print them. Sending bank can't know these values.

Having understood the logic of SWIFT messages, let's move directly to sending messages.

Hacker training logic
Since previously, we dealt with this from the point of view of SWIFT types, or other types put to us by hackers, or bank officers we need to understand their logic.

As a reminder, the goal is to get our message into a queue to get it through all validators and into the SWIFT NET.

To queue our message it will take two things:

1. Access to the correct queue manager (MO);
2. Record option in this MOE.

Depending on the bank/financial institution, there are different ways to gain access to IOs, sometimes very complicated. However, if we try to get access "from scratch", the scheme will look something like this:

1. The DOD Administrator accesses his dedicated workstation using AP data;
2. Gain remote access to the dedicated server via RDP as only the admin's computer is on the whitelist of those who can access the server.
3. An additional step may be required if the queue uses Channel Authentication Records, allowing only certain systems, or user accounts, access to a particular message queue.
4. It may require an extra step if channels are additionally protected by Message Encryption (MQME), which encrypts messages based on which channel they come from. Thus, even if you are the Chief Administrator of the entire Bank, you can read/write only to your dedicated queues, which are prescribed in the MQME configuration file.
5. Based on the inputs, we conclude that the IO administrator can use additional tools, such as Jump Server, to read/write to the desired message queues.

Thus, in this scenario, in order to access the message queues, the attacker would have to compromise the AP account of the IO administrator and the workstations, then use them to gain access to the jump host, from where he can already access the message queue, provided he knows the correct channel name, has the authorization configured to access it... and possibly route some MFA through there.

When discussing such sophisticated attacks on financial market infrastructure (FMI) in this paper, it is more reasonable to agree that Advanced Persistent Threat (APT) would be considered a feasible task. Therefore, let us consider the actual attack vector against the Bank.

A viable vector of attack
Having taken the idea of how to gain access by understanding all the technologies and security controls, we move on to a detailed breakdown of the attack vectors.

It is important to add that there are LAU (local authentication unit) channels between Swift Alliance Gateway adapters and the Bank (or other institutional financial institution (IFI)), just as there are between the Bank and the PPO (middleware 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 two systems. These keys are combined and used to generate a SHA256 HMAC message and add it to the S block (as we discussed earlier). These keys can then be verified and validated by the recipient system. In effect, this is verification of the authenticity and provenance of the message. Thus, even if an attacker sends a fraudulent payment from a dummy terminal, they first need to compromise the left and right LAU signing keys, or generate a valid HMAC and add it to the message so that it is accepted and successfully processed. (which again leads to the conclusion that liars saying they are spoofing the bank server are nothing more than liars).

But leaving LAU aside for now, first we need to define what will be our target. After all, there are essentially 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 should be in the format expected by the target system (it depends on the specific outgoing system) and the outgoing one should be in the format that will be accepted and processed according to the rules. So let's go from the end.

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 freely available for sale), explore every corner of the system, which is not likely.

Implementing SWIFT, LAU on messages between adapters, is a great way to secure the communication channel. Which eliminates the possibility of an attack in that direction.

Note: You have probably come across manual downloads, and ledger 2 ledger on the Internet. So, this is the delicate place where you can wire this message. Thousands of Chinese hackers can't do that either.

Target BANK

Let's drop 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 lifecycle. Given the fact that we don't know how to generate these values without gaining access to the bank's entire infrastructure as well as the encrypted data on their servers, it doesn't look possible at this point to consider the Bank as a target.

Purpose Software (FS)

In order for the SRP to be your target, you must enter a message in the Bank's "incoming" queue, or the SRP's outgoing queue. In essence, it should match the format of the messages that the VSP issues. Once the VSP starts the message in the bank's queue, in theory we will have both a session number and a sequence number added to the message, together with a UETR code. This is an extremely interesting attack vector.

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

Purpose The Bank's Payment System (PS)

As 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 this is an extremely interesting concept.

How do we oWt about outbound queues?

Even though the COP receives data in a custom format, the outbound message vaguely resembles a SWIFT MT. Which for a hacker would be an ideal vector for an attack. Also, the SAR has no LAU between it and the PPO because, unlike the PPO, the SAR is not a SWIFT messaging partner. It is only one of the few payment systems within the Bank.

In addition, because the SP 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 on the corporate network to authenticate MO1. Also, a hacker could subsequently write the payment order to the "outbound queue" of the payment system.

Let's formulate what we want:

In theory, why this should work is because the PGO is an application that implicitly trusts everything it receives from the relevant upstream systems. This is done deliberately because, by design of the security model, a sending message can be generated at any point in time. If there is a system whose goal is to ensure the validity of a payment message at any point upstream, then downstream systems should have no problem handling these messages (with some exceptions). Without this design, it is at least impossible to maintain a high-performance payment system.

The plan is this:

• to use the IO administrator's access;
• abuse the "relationship of trust" between the PS, SRP and the Bank
• enter the payment message to the outgoing queue of the PS;
• MT103 payment order, must pass all validators.

A hacker triggers a payment
After we understand a bit about how the system works, we check the elements we need to send SWIFT.

• Target system;
• Message format;
• Queue manager;
• Required queue;
• Write, read, access rights at administrator level;
• Access to SWIFT message exchange;
• Fake message.

Now, the hacker needs to create a valid payment message using the real company details at the target institution. This, by the way, 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 details will be fake for the sake of the article. I.e. these are not real details.

The sender account details are John Doe, GB12EBNK98765412345678 to EBNKG20;

Recipient account details - Alise Smith, GB15EBNK9876587654321 on EBNKG20;

You may have noticed that the sender and the recipient have identical BIC. For the purposes of this article this is because our hacker wants to see how the message is processed via SWIFTNet and was able to analyse the message from start to finish. Furthermore, we use the BIC code for "test&training".

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

Now with access to those "real account credentials" and the knowledge you have after reading this article we generate an outgoing MT103 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 receiver country code belong to the same country, then field 33B is mandatory". Therefore, if 33B is missing, the network checking rules will fail and SWIFTNet will return the NAK with error code: D49

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

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

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

Do not forget to add a decimal comma in the transaction amount. Otherwise, the syntax rules will be broken and the message will not pass the SWIFTNet check.

Please make sure that the IBAN is accurate, otherwise the message will not understand which SWIFT signature type will apply. In our article the IBANs are fake and unbreakable, but hackers need to use legitimate data in their work.

It remains for us to delete only the trailer block (5) - as it will also be added to the BANK. We delete the system unit for the same reason.

The final message is as follows:

{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 were thinking about were overshadowed. The deeper we dug into the wilds of SWIFT, the easier it became to compose the message.

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

• Through access to the queue manager's account, connect to his computer;
• Let's go to the server;
• Opens our tools for working with managers, login in queue manager, at the moment of the outgoing queue of the Payment System;
• Connecting to the queue;
• Select our file 103.txt;
• Call the "queue recording" function;
• And... the surgery's done.

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

ACK. It works. (Note: actually, of course, it's unlikely to work the first time. When I learned SWIFT, all my times were NAK, and those are corrections in the text of messages, it is only the result of practice in composing messages, and finding errors in these messages, not to be noticed by a legitimate operator)

With such a payment order, we will be able to work out the message within the bank. But it is not the same to send a message to another bank.

And that's where a lot of other things come up, where MT103 processing alone is not enough. 103, only a payment notice, but with it the money will not necessarily fall into the account (this is only possible with direct correspondent relationships between banks). Moreover, the chance of doing it any way legally drops dramatically, because the message will be checked by intermediary banks. Therefore, digging further.

Figuring out where you lost your money
So, we sent MT103 and it even made it to the target institution. But where is the money? Here everything is quite ambiguous, because for the money to be credited, it has to be debited from somewhere. But first things first.

To begin with, let us understand how in general the process of writing off money within the bank takes place. For example we have a client A and client B in Deutsche Bank (hereinafter DB). I (client A) want to send 10 euro to my friend (client B). I just need to inform the bank of my intentions, and the bank will debit my account with 10 euro, and credit the money to the account of my friend. In essence the procedure is carried out within the bank's Payment System, within the bank itself. The money does not enter the bank, nor is it withdrawn from it, it is simply recorded in the internal accounting and everything balances out.

But what if Customer B, is at another bank, for example HSBC. DB will not have a problem to write off 10 euros from my account, but how will our bank make sure that HSBC credited to Customer B's account - 10 euros? Why would HSBC agree to be more indebted to Customer B than before? Essentially, they would be agreeing to such a transaction in order to be owed more by someone else, if someone else, they would end up owing a little less to.

The very other person they owe less to may not be Customer A, as we are not connected to their bank in any way, nor do we even have accounts at HSBC. In that case, can they contact banks with each other? For example DB will open its account with HSBC and HSBC will open its account with DB.

Then the scheme would look like this:

• DB deducts EUR 10 from Client A's account;
• DB adds €10 to the HSBC account opened with DB;
• DB notifies HSBC that €10 has been credited to their account and they wish to transfer the €10 to Customer B;
• HSBC knowing that there is 10 euros more on their DB deposit, can replenish customer B's account with this money.

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

This model of payment processing is an activity of banks based on correspondent relationships. We have analyzed only the simplest scheme, with banks communicating directly with each other. But sometimes you have to use the third or even fourth bank in the chain, until the payment reaches the Beneficiary. This of course increases the cost and complexity of such payments.

Also, the bank is concerned that this is a very risky type of payment. Let us see how it looks from the bank's point of view. 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 and more reliable operator. In this case, HSBC would have great difficulties if the small bank goes bankrupt. In such a case, of course you could ask not to credit the HSBC account to DB, but ask HSBC to debit the money from the DB account to HSBC. But in that case, there are other problems inherent in large funds movements.

It is also worth considering that the SWIFT network costs money. If DB needs to send a message on the SWIFT network about every transfer to customer B's account - 10 euros. Then soon the number of costs in the statement will multiply. And worst of all, a liquidity problem emerges. Imagine how much money DB would need to have in correspondent banks' accounts in case any of the clients wished to transfer money to HSBC, or Lloyds, or Citi, or any other bank. That same money could also be invested in assets, lent out, spent or run in trading where it would generate income for the bank.

This is why banks do things a little differently. Most banks keep track of all the multiple 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 sums in their correspondent bank accounts, and this money can be used more efficiently. In particular, it reduces the costs of banks and allows them not to keep huge amounts of money frozen in the correspondent accounts of other banks.

But there are threats with this approach as well - loss of settlement finality. You can send a payment early in the morning, but the beneficiary bank will not receive the money until a certain point. After all, at any point in the day, before the settlement is completed, the sender may go bankrupt during the transfer: crediting the recipient's account by the receiving bank is a rash move. And so there is a delay.

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

But how do we reach consensus and have zero risk for the counterparty?

After all, none of the approaches described above can be applied and be absolutely certain that the payment will be made quickly, it cannot be reversed and the sending bank will not go bankrupt in the future. You need this type of guarantee, but alas, no one will give you a guarantee of 100 million euro in bonds or shares, if there is a risk that the 100 million will not be paid or cannot be recovered.

This is where the central bank system comes in. This is what systems like CHAPS, FedWire, Target 2 were created for, which deal with transfers of pounds, dollars and euros respectively. These systems perform real-time movement of funds between the accounts that banks have with the respective Central Bank (i.e. all of the largest banks in the country, have an account at the central bank, where they can transfer money from one bank to another, simply by giving instructions to the Central Bank to debit one account and credit the other). This is essentially a real-time gross settlement system (Note: no debt accounting, i.e. instantaneous, completed, with no possibility of refunds).

And just now, we'll talk about Mt202 coverage. When you send SWOFT for small amount - beneficiary bank, checks its account replenishment for this amount in correspondent bank, in case of absence of replenishment of beneficiary bank account, it debits this funds from account of sender bank in its bank, and transfers payment further on chain. The account debit will be reflected in the statement of the sending bank, thereby indicating that the funds have gone to the beneficiary. If there is no balance or there is not enough liquidity on this account, the account may be closed and in the case of central banks there may be a threat of revocation of the license due to the liquidity, which will reveal the fraudulent scheme and the hacker who made the transfer.

Which leads to a simple conclusion. Money in cor. accounts does not lie in large quantities. Even in large banks, the size of these accounts rarely exceeds 50 million euros. Billions are out of the question. According to

A little bit about real hackers
And yet, SWIFT systems have been hacked. I mean, small banks and their corporate networks have been broken into. But there have been hacks. And so have attempts to send SWIFTs. Despite the fact that hackers have a lot of other methods to help them withdraw huge amounts of capital in a short period of time, with this level of access.

But we'll break down, lastly, what things hackers have to do in order for your payment to be successfully processed, and get to the beneficiary in an automated fashion.

Purely hypothetically, a hacker could own an account where there are finances, at the right bank. Then an MT103 payment order would suffice. Legitimate operator in 100% cases will see and process the payment. Withdraw the money from your correspondent account and send it through the bank channel. But in most cases, by accessing the banking infrastructure you do not gain access to the companies and their money, so the hackers will have to operate with the money on the root account.

And then they have to resort to all sorts of tricks. Forging legitimate programs by embedding backdoor, printer queues, forging and intercepting email on bank mail servers, and so forth. This is a very long, painstaking and expensive operation, with no margin for error. Simple philistines from the Internet, who want to keep their pockets wide open for free, so that someone will send them money, and from this money they have already returned to you - no one needs.

In 99% of cases, all this works through pre-established channels, with people known to each other and get into these circles from the outside just possessing and flapping pretty eyes will not work.

Afterword
Bottom line. Working on SWIFT is long, painstaking, and very expensive. It is associated with high risks, and the possibility of going to jail. That's why it's highly recommended that you avoid this kind of activity. In most of all, you are likely to be caught in a divorce, and even if you are not, then after work there is a good chance that your "techie", not a particularly that a professional, and will not pass a couple of days, as to you together with a warrant for the arrest will come the citizens in uniform. The money will of course be withdrawn, and their withdrawal from the account, or further movement will be an aggravating factor in your future case.

And this is not a scarecrow for intimidation, but real life cases that happen every year. Successful withdrawal operations are very few. And they are carried out in very narrow circles, by people known to all bankers. Probably, you even know them since you are reading this article.

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

Peace, everyone. Work with professionals, make money, not chase air on the internet.