Travel banking transaction

[Tomcat]

Some time ago, there were already posts about the operation of ATMs, but both of them described the principles of operation of ATMs and card processing in general very superficially.

For those interested, under the cut there are many details of the bank’s card processing (many letters).
What does a simplified operation diagram of a bank’s processing center look like:

Processing​

FrontEnd - is responsible for online messages: communication with ATMs and POS terminals, transfer of card authorizations to VISA.
BackEnd - is responsible for offline: closing the operating day, exchanging financial messages with VISA.
HSM (Hardware Security Module) is a module for working with security keys (described in more detail below).

All encryption is done using the 3DES algorithm.

Connection to VISA​

The bank has two types of connection to VISA:

• online
• offline

Online connection​

Transport layer
Connection to VISA is carried out through a very specific provider, in 2006 it was Equant and its partner in Russia - Golden Telecom, I don’t know what the situation is now.

It turns out that VISA is available on the local network of one provider. This is a mandatory VISA requirement. To connect, the provider lays its own fiber-optic cable to the bank for the main communication channel and for the backup one. Installs end routers and allocates one port on each (primary and backup). Routers are managed only by the provider.

So, the connection between the transport layer and VISA is established, then the application layer.

Application layer
Application layer communication is carried out using a special protocol developed in VISA in ancient times.

In addition to all this, all messages must be transmitted encrypted. To do this, special people - security officers - generate key sequences of a given length on the HSM and the results are sent to VISA.

Offline connection​

An offline connection is nothing more than an exchange of files with information about all transactions made during a business day. That is, if the ATMs of bank “A” processed cards other than bank “A”. More about this below in the scenario “Another client in our ATM”.

It’s worth telling a little about HSM.

HSM​

HSM is a classic black box. When initialized, it generates the private and public components of the bank's master key. No one ever sees a private component; it always remains in the HSM memory.

The module itself has numerous levels of protection against hacking: software and physical. At the slightest hint of compromise of the key, the module’s memory self-destructs without the possibility of recovery.

Three parts of the public component of the master key are recorded on 3 magnetic cards and issued to the bank's security officers.

So, the connection with VISA is established, and everything works. Now we need to issue cards.
When joining a VISA, the bank is issued so-called BINs (Bank Identification Number): that is, a subset of card numbers available for issue. For VISA they always start with 4.

BINs are distributed according to card products, for example:

• VISA Classic: 400001
• VISA Gold: 400002
• VISA instant issue: 400003
• and so on

The number format looks like this: let's say we have a card with the number: 4408 0412 3456 7890

The card number consists of:

• 4ХХХХХ - VISA code
• 4408(04) - bank code (card product code)
• 12 3456 7890 — authorization limit number. Read more about the authorization limit below.

For those interested, here is a description of how the card number is validated.

For each BIN, a pair of keys is generated: IWK (issuer working key) and AWK (acquirer working key). The procedure for generating and transmitting the result to VISA is similar to that described above.

After that, all this stuff is registered in the FrontEnd and BackEnd of processing. In BackEnd for issuing cards and their embossing, in FrontEnd for servicing authorizations.

Now we have a connection with VISA and have issued cards; in other words, we issued cards. All we have to do is acquire.

ATMs​

I will not repeat myself and describe what is inside the ATM, it has already been described here. Let me just say that the NDC+ (NCR Direct Connect) protocol was developed God knows how many years ago by NCR Corporation, one of the leading ATM manufacturers today.

Three manufacturers are widely known:

• NCR
• Wincor Nixdorf GmBH (formerly Siemens Nixdorf)
• Diebold (formerly IBM)

Yes, both Siemens and IBM once made ATMs, but later sold this business to Wincor Nixdorf and Diebold, respectively.
Your humble servant is a certified engineer at Wincor Nixdorf. However, we had one old IBM that was released before the sale of the business that worked.
I won’t say that it worked like a charm, because it had to be tightened and adjusted all the time so that it would somehow breathe, but it was possible to buy spare parts for it. True, they cost three times more than similar ones for Wincor Nixdorf.
So, we found out that there are two protocols by which ATMs operate. I only had the opportunity to work with NDC+, I only heard about DDC, but never saw it.
Since I am only intimately familiar with Wincor Nixdorf, let's assume that our bank bought them.

When the software that controls all its numerous devices is installed on the ATM, the ATM must be prepared for operation.

Preparing an ATM​

Education​

The ATM must be trained to dispense banknotes. There is a special procedure for this: the ATM counts 10 sheets from each cassette and prompts the operator to enter the actual number of sheets counted. If the actual quantity is different, the ATM will adjust the optocouplers in the dispensing path and offer to repeat the procedure.

From experience, I have only had an ATM make a mistake a couple of times, which means, as a rule, they are already well calibrated from the factory.

Encryption keys​

2 encryption keys are loaded into the ATM:
master key (MASTER KEY) - used to encrypt the PIN block entered by the client.
communication key (COMM KEY) - to encrypt the package to the FrontEnd of processing.

The public and private components of each key are generated on the HSM, after which the public component is registered in the FrontEnd, and the private component is loaded into the ATM.
Both keys are loaded into the PIN keyboard (EPP Encrypted Pin Pad) and stored only there. Essentially, EPP is a small HSM that cannot generate keys, but can store them very well. When I worked closely with ATMs, EPPs had 7 levels of protection against physical penetration.

After that, we register the processing address, set up a VPN or whatever the telecommunications guys come up with, and you can download the ATM operation script.

Scenario​

The script has already been mentioned in the article to which I referred, I just want to add a little.
The entire ATM scenario is based on the so-called FITs (Financial Institution Table).
FIT is nothing more than a bank BIN issued by VISA.
For example: for our home bank we will allow transfers from card to card, the ability to view details of a deposit and deposit cash into a card account in addition to the usual capabilities (balance, cash withdrawal), and for everyone else only balance and withdrawal.

Thus, we must load several FITs into the ATM:

• 400001, 400002, 400003 - we will allow anything and everything
• 999999 - issue and balance only

The script checks the customer's card number and works on the first match in the FIT table.

So, we have fully prepared the entire complex for work, the most important thing remains: to complete the transaction.

Transaction​

The simplest scenario: our client in our ATM:

1. The client inserts the card into the ATM;
2. ATM sees that the client is ours and gives him options;
3. The client chooses: delivery, 100 rubles
4. The ATM encrypts the PIN block with a master key;
5. Encrypts the entire message with the communication key and sends it to the FrontEnd;
6. FrontEnd receives the message;
7. the ATM is identified by ID (each ATM is connected to its own port, so there are no problems getting the ID);
8. Decrypts the message with the public component of the communication key;
9. by BIN it understands that the card is ours;
10. Decrypts the PIN block with the open component of the master key;
11. Processes a request for debit (whether there is money, whether the limits have been reached, and so on);
12. Encrypts the message with the public component of the communication key;
13. Sends to ATM;
14. The ATM decrypts the message;
15. Communicates the result to the client;
16. Notifies the host that the money has been issued (also with encryption and everything else).

It is worth noting that all encryption on the host side is carried out using HSM.
That is, steps 8 and 9 in detail look like this:

1. The host sends an encrypted PIN block, master key and checksum to the HSM;
2. HSM decrypts the PIN block;
3. Verifies the checksum after decryption with the one sent;
4. Encrypts the open PIN block using IWK and calculates the checksum;
5. If the checksums of the open PIN block and the encrypted IWK are equal, the PIN was entered correctly.

The client receives his 100 rubles and leaves satisfied, but this is only half the battle.

At this moment, FrontEnd set a hold for the client - it froze 100 rubles on his authorization limit (the amount available for withdrawal), but his current account did not change at all.

It’s worth clarifying a little here: there are no customer accounts in processing - the movement of money occurs according to the so-called “authorization limits”. In fact, the authorization limit is nothing more than the client’s card account, but it does not appear in the chart of accounts and balance sheet.

In other words, the authorization limit is a technical entity that reflects the state of the client’s real current account in processing. The difference between the authorization limit is that:

1. the authorization limit is subject to processing limits: a one-time issuance limit, a daily issuance limit, and so on;
2. the authorization limit can change during the operating day, the current account is only at the close of the operating day.

In the evening of the current day or the morning of the next day (but, as a rule, this is done at night), the operating day closes. All card authorizations and holding amounts are downloaded from FrontEnd and loaded into BackEnd, where money flows through clients’ current accounts. After this, the final reports are uploaded to the Automated Banking System, where current client accounts are stored. Based on these reports, real money movement occurs, as well as new authorization limits in the FrontEnd (our client from the example above receives a new authorization limit, which is 100 rubles less).

Now it’s more difficult: Someone else’s client in our ATM:

1. The client inserts the card into the ATM;
2. ATM understands that the client is a stranger, shows him only the balance and issue;
3. The client chooses: delivery, 200 rubles
4. ATM encrypts the PIN block with a master key;
5. Encrypts the message with a communication key;
6. Sends a message to the FrontEnd;
7. FrontEnd decrypts the message with the public component of the communication key;
8. Determines that the BIN is not ours and must be sent to VISA;
9. FrontEnd encrypts the message with the AWK component (since we are the acquirer in this case) and sends it to VISA;
10. VISA receives a message from us, decrypts it with the second component of our AWK and uses the BIN to determine which bank the card is;
11. Encrypts the message with the IWK component (since it addresses the issuer) of the bank that issued this card and sends the message;
12. The issuing bank receives a message:
13. Decrypts the message using the private IWK component (it’s immediately clear that the card is ours, there’s no point in looking at the BIN);
14. Decrypts the PIN block;
15. Authorizes the card (gives approval for issuing 200 rubles);
16. Encrypts the message with a private IWK component and sends it to VISA;
17. VISA decrypts the issuing bank's IWK with the open component, encrypts our bank's AWK with the open component and sends it to us;
18. We decrypt the message with a private AWK component;
19. We record the result of the transaction;
20. We encrypt it with the open component of the communication key of the desired ATM and send it a message;
21. The ATM receives the message, decrypts it and issues money to the client;
22. Notifies the host that the money has been issued (again, I encrypt all messages);
23. We notify the issuing bank that the money has been successfully issued;

This was only authorization, that is, no one transferred real money to anyone. Now we need to receive a financial message about this transaction and receive a refund from another bank: 200 rubles of our money, which we gave to its client.

1. We send a report to VISA (offline, slowly and sadly) that it was not our client with such and such a card number who received 200 rubles from our ATM;
2. VISA sends a request to the issuing bank to transfer us 200 rubles and another 0.5% of the transaction amount, but not less than $3 to VISA itself for carrying out the transaction through itself. This is the so-called interchange fee;
3. The issuing bank receives files from VISA, closes its operational day in processing, then closes the day in the Automated Banking System and transfers through the correspondent. VISA bank to our account our 200 rubles;
4. Calculated with VISA (covers interchange fee)

Of course, all such calculations are carried out in dollars, and exchange rate differences play a role here, but that’s a completely different story...