Friend
Professional
- Messages
- 2,675
- Reaction score
- 1,052
- Points
- 113
I read a lot of articles about bank cards, ATMs, and now I decided to contribute. Below I will try to talk about how an ATM is arranged in terms of software.
What is an ATM?
Any ATM is essentially a computer with connected peripherals, an equipment manager and the actual banking application that controls this entire economy. All decisions on the issue of money are made by the server. The ATM only collects information from the client and transmits it to the server.
ATM iron
The minimum set of ATM hardware includes:
- card reader for reading the client's card
- pin-pad, for entering a pin-code and other information such as the amount of payment / withdrawal
- function keys on the sides (4 + 4) are an addition to the pin-pad. In some modern ATMs, they have been replaced by a touch screen.
- dispenser for dispensing money
- various sensors, backlight
Who runs this whole zoo
In order for manufacturers not to suffer with writing drivers, which then no one needs, and software developers did not suffer from a variety of solutions for managing a particular piece of hardware, it was decided to unify the whole thing.
This is how the CEN / XFS standard or simply XFS appeared, which stands for eXtension For Financial Services.
The standard describes a client-server architecture consisting of a hardware manager and service providers (read device drivers) that it manages. In the terminology of the standard, a "service provider" is a library that provides a specific set of functions for obtaining information about a device and managing it. Usually it is a dynamic library containing a certain set of standard functions (Open, Close, GetInfo, Execute), each of which has a number of device-specific arguments.
All interaction with the equipment takes place through the XFS manager API. For example, the Command parameter of the Execute function can be set to a bill dispenser:
WFS_CMD_CDM_DISPENSE (money set from cassettes)
WFS_CMD_CDM_PRESENT (Dispense Pack to Customer)
For a card reader:
WFS_CMD_IDC_RETAIN_CARD (capture card),
WFS_CMD_IDC_READ_TRACK (read tracks)
There are several implementations of XFS managers (including open source ones) written in c ++ and, in theory, service provider libraries written for one manager should also fit all the others, but in fact sometimes a library written by a specific vendor for a specific XFS manager, works only with this manager.
There is also Java XFS with its libraries that are not compatible with classic managers.
Banking application
The banking application is what you see on the screen when you approach the device. It is designed to collect data from the user, send this data to the host (server) and perform a response from the host. As with hardware (XFS), there are industry protocols (NDC / DDC) through which the application communicates with the host, downloads the configuration, and interprets it.
Any major ATM manufacturer (Wincor, NCR, Diebold) has its own implementation of both XFS and banking applications.
However, there is alternative software on the market that meets all standards and is not tied to a specific vendor.
I will describe an ATM using the example of NDC as the most common protocol in Russia, but the slightly less popular DDC has a similar principle of operation.
How does it work
At each moment of time the ATM is in one of the operating modes:
- Power Up - Loading
- Offline - There is no connection with the server, we connect
- Supervisor - collector or service engineer is working
- Out of service - the ATM does not work because it is out of order, the money has run out, or someone in the bank simply switched it to this mode.
- In service - the main mode of operation, familiar to all those who have bank cards.
In the In service mode, the ATM is in one of the states (state), with a number from 001 to 999, and a 25-character description string.
The first character of this line is the state type (denoted by the letters A..Z and also a..z and some characters (, '.?)), It defines a collection. The remaining 24 characters are 8 decimal 3-digit numbers, each of which is a specific state setting (screen number to display, conditions for moving to a state, list of actions). There can be any number of states of the same type.
In service mode
At the start of the service mode, the ATM automatically starts to execute state 000. Usually this is state A (Card read state). In this state, the ATM displays a screen with an invitation to insert a card and switches the card reader to accept mode. Also, the state is responsible for reading the map and branching depending on the results of this operation.
Below is an example of the configuration for a typical state A:
000 A001001011008004002001104
000 - state number
A - state type (Card read state)
001 - screen number
001 - number of the state, to which to switch in case of successful card reading
011 - state number to switch to in case of card reading errors
008 - read condition 1
004 - read condition 2
002 - read condition 3
001 - the condition for the return of the card (immediately after reading or upon completion of the operation)
104 - transition state, if the card is unknown to the bank
Let's go through the parameters in more detail:
State type - everything is clear here: having determined the state type, the application knows how to interpret further parameters.
Screen number - is a link to a line with a textual description of the screen that is displayed during the operation of this state.
Not every state has a screen.
A screen can be numbered from 000 to 999. Screens differing by 100 are usually reserved for different languages. Thus, screen 010 and screen 210 are most likely multilingual versions of the same screen. I'll talk about screens a little later.
The number of the transition state in case of a successful card reading is what state the application will start to execute if the card is recognized and the data is read successfully.
In addition to the states and screens in the ATM, there is another important configuration parameter - the financial institution table. The table of financial institutions contains data on which cards belong to which bank, how to parse the data read from the card tracks correctly, and what to do next depending on this data. For example, if the card is local, then you can execute one script, if the card is a third-party bank, then you need to disable the script branch with mobile payments and balance check.
The number of the transition state in case of problems with reading the card - if the card could not be read according to any of the proposed conditions - go to the state specified in this parameter. As a rule, this is the state J (Close state) on which we give the card, show a screen with a proposal to pick it up and activate a timer after which the mechanism of holding the card will be launched. State J is also the last state in case of a successful transaction.
The conditions for reading the card (3 parameters in a row) are bit masks indicating the track numbers to be read and the interaction with the chip, if any.
For example, Read Chip, Read Track 2 and Track 1, Read Track 1. If at least one of the conditions is triggered, the other conditions are not met and the card is considered read. If none of the conditions are met, the card is considered unread.
The condition for the return of the card - the ATM can return the cards immediately after reading, or it can do it at the end after all operations are completed.
The rest of the states are arranged in a similar way:
- There are states for reading the sum from the keyboard and placing it in a special internal buffer;
- There are states for reading the pin-code with a pin-pad and then receiving the pin-block into a special buffer;
- There are states to check the entered data (for example, if the entered amount is less than the minimum amount, then there is a redirection to the state with an error message);
- There are states for selection using the side keys (the so-called FDK) and placing the characters of these keys (ABCD FGHI) in a special 8-byte buffer;
- There are states for zeroing and presetting buffers.
Going through all these states, the application sooner or later reaches the state of interaction with the host - state I (Transaction Request State). On this state, a request is formed from the data collected on previous states and sent to the server. The request is an ATM ID (Logical Unit Number), data from the card tracks, data on previous transactions, data from the amount buffers, pin-block, keystrokes (FDK buffer). The data is separated by a delimiter character. The server application receives the request and analyzes the FDK buffer - it is by the content of this buffer that the host understands what the ATM wants. After that, depending on the decision made, he sends an answer that contains:
the identifier of the action to be performed;
the number of the screen that needs to be shown during this action;
the contents of the check, if the check needs to be printed;
the state to which you need to go on completion of the action.
In a special buffer, the number of notes to be dispensed from each cassette is transmitted (if this is a cash withdrawal operation). It is the number of bills, because the ATM does not know the denominations of the money issued for it, these are just pieces of paper in cassettes.
Upon completion of the required actions, the application sends a confirmation to the host and goes to the specified state. As a rule, this is the state J already known to us. In case of any failure, the application sends a message about the failure to the host and waits for a new Transaction Reply with the transition to the new state.
Now about screens
The ATM screen is a field of 32x16 cells. The screen can contain both graphic information and text, which is positioned relative to the cells. Fonts can be double height.
The screen description is a line of text interspersed with control characters such as screen clearing, cursor positioning, font size. In most modern banks today, text is used only when entering amounts, and in other cases the screen is just a solid picture. However, there are also completely text screens.
An example of a screen displaying a picture from a table of pictures (\ 0c \ 1bP2018 \ 1b \ 5c)
These are the screens that state parameters refer to.
The collection of states, screens, FITs, timers is called an ATM scenario. Each scenario has its own number. After loading the ATM and connecting it to the network, it sends a message to the host in which it reports its ID and configuration number. If the configuration needs to be updated, the host switches the ATM to the "Out Of Service" mode and starts loading the necessary parameters of the new configuration. The last parameter is the configuration number. In a similar way, the keys are loaded for encrypting the pin block, for dummy, and master keys.
In short, this is how an ATM works. I hope someone will find this information useful.
What is an ATM?
Any ATM is essentially a computer with connected peripherals, an equipment manager and the actual banking application that controls this entire economy. All decisions on the issue of money are made by the server. The ATM only collects information from the client and transmits it to the server.
ATM iron
The minimum set of ATM hardware includes:
- card reader for reading the client's card
- pin-pad, for entering a pin-code and other information such as the amount of payment / withdrawal
- function keys on the sides (4 + 4) are an addition to the pin-pad. In some modern ATMs, they have been replaced by a touch screen.
- dispenser for dispensing money
- various sensors, backlight
Who runs this whole zoo
In order for manufacturers not to suffer with writing drivers, which then no one needs, and software developers did not suffer from a variety of solutions for managing a particular piece of hardware, it was decided to unify the whole thing.
This is how the CEN / XFS standard or simply XFS appeared, which stands for eXtension For Financial Services.
The standard describes a client-server architecture consisting of a hardware manager and service providers (read device drivers) that it manages. In the terminology of the standard, a "service provider" is a library that provides a specific set of functions for obtaining information about a device and managing it. Usually it is a dynamic library containing a certain set of standard functions (Open, Close, GetInfo, Execute), each of which has a number of device-specific arguments.
All interaction with the equipment takes place through the XFS manager API. For example, the Command parameter of the Execute function can be set to a bill dispenser:
WFS_CMD_CDM_DISPENSE (money set from cassettes)
WFS_CMD_CDM_PRESENT (Dispense Pack to Customer)
For a card reader:
WFS_CMD_IDC_RETAIN_CARD (capture card),
WFS_CMD_IDC_READ_TRACK (read tracks)
There are several implementations of XFS managers (including open source ones) written in c ++ and, in theory, service provider libraries written for one manager should also fit all the others, but in fact sometimes a library written by a specific vendor for a specific XFS manager, works only with this manager.
There is also Java XFS with its libraries that are not compatible with classic managers.
Banking application
The banking application is what you see on the screen when you approach the device. It is designed to collect data from the user, send this data to the host (server) and perform a response from the host. As with hardware (XFS), there are industry protocols (NDC / DDC) through which the application communicates with the host, downloads the configuration, and interprets it.
Any major ATM manufacturer (Wincor, NCR, Diebold) has its own implementation of both XFS and banking applications.
However, there is alternative software on the market that meets all standards and is not tied to a specific vendor.
I will describe an ATM using the example of NDC as the most common protocol in Russia, but the slightly less popular DDC has a similar principle of operation.
How does it work
At each moment of time the ATM is in one of the operating modes:
- Power Up - Loading
- Offline - There is no connection with the server, we connect
- Supervisor - collector or service engineer is working
- Out of service - the ATM does not work because it is out of order, the money has run out, or someone in the bank simply switched it to this mode.
- In service - the main mode of operation, familiar to all those who have bank cards.
In the In service mode, the ATM is in one of the states (state), with a number from 001 to 999, and a 25-character description string.
The first character of this line is the state type (denoted by the letters A..Z and also a..z and some characters (, '.?)), It defines a collection. The remaining 24 characters are 8 decimal 3-digit numbers, each of which is a specific state setting (screen number to display, conditions for moving to a state, list of actions). There can be any number of states of the same type.
In service mode
At the start of the service mode, the ATM automatically starts to execute state 000. Usually this is state A (Card read state). In this state, the ATM displays a screen with an invitation to insert a card and switches the card reader to accept mode. Also, the state is responsible for reading the map and branching depending on the results of this operation.
Below is an example of the configuration for a typical state A:
000 A001001011008004002001104
000 - state number
A - state type (Card read state)
001 - screen number
001 - number of the state, to which to switch in case of successful card reading
011 - state number to switch to in case of card reading errors
008 - read condition 1
004 - read condition 2
002 - read condition 3
001 - the condition for the return of the card (immediately after reading or upon completion of the operation)
104 - transition state, if the card is unknown to the bank
Let's go through the parameters in more detail:
State type - everything is clear here: having determined the state type, the application knows how to interpret further parameters.
Screen number - is a link to a line with a textual description of the screen that is displayed during the operation of this state.
Not every state has a screen.
A screen can be numbered from 000 to 999. Screens differing by 100 are usually reserved for different languages. Thus, screen 010 and screen 210 are most likely multilingual versions of the same screen. I'll talk about screens a little later.
The number of the transition state in case of a successful card reading is what state the application will start to execute if the card is recognized and the data is read successfully.
In addition to the states and screens in the ATM, there is another important configuration parameter - the financial institution table. The table of financial institutions contains data on which cards belong to which bank, how to parse the data read from the card tracks correctly, and what to do next depending on this data. For example, if the card is local, then you can execute one script, if the card is a third-party bank, then you need to disable the script branch with mobile payments and balance check.
The number of the transition state in case of problems with reading the card - if the card could not be read according to any of the proposed conditions - go to the state specified in this parameter. As a rule, this is the state J (Close state) on which we give the card, show a screen with a proposal to pick it up and activate a timer after which the mechanism of holding the card will be launched. State J is also the last state in case of a successful transaction.
The conditions for reading the card (3 parameters in a row) are bit masks indicating the track numbers to be read and the interaction with the chip, if any.
For example, Read Chip, Read Track 2 and Track 1, Read Track 1. If at least one of the conditions is triggered, the other conditions are not met and the card is considered read. If none of the conditions are met, the card is considered unread.
The condition for the return of the card - the ATM can return the cards immediately after reading, or it can do it at the end after all operations are completed.
The rest of the states are arranged in a similar way:
- There are states for reading the sum from the keyboard and placing it in a special internal buffer;
- There are states for reading the pin-code with a pin-pad and then receiving the pin-block into a special buffer;
- There are states to check the entered data (for example, if the entered amount is less than the minimum amount, then there is a redirection to the state with an error message);
- There are states for selection using the side keys (the so-called FDK) and placing the characters of these keys (ABCD FGHI) in a special 8-byte buffer;
- There are states for zeroing and presetting buffers.
Going through all these states, the application sooner or later reaches the state of interaction with the host - state I (Transaction Request State). On this state, a request is formed from the data collected on previous states and sent to the server. The request is an ATM ID (Logical Unit Number), data from the card tracks, data on previous transactions, data from the amount buffers, pin-block, keystrokes (FDK buffer). The data is separated by a delimiter character. The server application receives the request and analyzes the FDK buffer - it is by the content of this buffer that the host understands what the ATM wants. After that, depending on the decision made, he sends an answer that contains:
the identifier of the action to be performed;
the number of the screen that needs to be shown during this action;
the contents of the check, if the check needs to be printed;
the state to which you need to go on completion of the action.
In a special buffer, the number of notes to be dispensed from each cassette is transmitted (if this is a cash withdrawal operation). It is the number of bills, because the ATM does not know the denominations of the money issued for it, these are just pieces of paper in cassettes.
Upon completion of the required actions, the application sends a confirmation to the host and goes to the specified state. As a rule, this is the state J already known to us. In case of any failure, the application sends a message about the failure to the host and waits for a new Transaction Reply with the transition to the new state.
Now about screens
The ATM screen is a field of 32x16 cells. The screen can contain both graphic information and text, which is positioned relative to the cells. Fonts can be double height.
The screen description is a line of text interspersed with control characters such as screen clearing, cursor positioning, font size. In most modern banks today, text is used only when entering amounts, and in other cases the screen is just a solid picture. However, there are also completely text screens.
An example of a screen displaying a picture from a table of pictures (\ 0c \ 1bP2018 \ 1b \ 5c)
These are the screens that state parameters refer to.
The collection of states, screens, FITs, timers is called an ATM scenario. Each scenario has its own number. After loading the ATM and connecting it to the network, it sends a message to the host in which it reports its ID and configuration number. If the configuration needs to be updated, the host switches the ATM to the "Out Of Service" mode and starts loading the necessary parameters of the new configuration. The last parameter is the configuration number. In a similar way, the keys are loaded for encrypting the pin block, for dummy, and master keys.
In short, this is how an ATM works. I hope someone will find this information useful.
