Under the hood of ATM software
I read a lot of articles on bank cards and ATMs on GT and Habré, and so I decided to make my contribution. Below I will try to talk about how the ATM is arranged in terms of software.
Any ATM is essentially a computer with peripherals connected, an equipment manager and the actual banking application that manages this entire economy. All decisions on issuing money are made by the server. The ATM only collects information from the client and transfers it to the server.
The minimum set of ATM iron includes:
In order to prevent manufacturers from writing drivers that no one needs then, 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.
So the CEN / XFS standard appeared, or simply XFS , 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 “service provider” standard, it is a library that provides a certain set of functions for receiving information about the device and managing it. Usually this 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 equipment occurs through the XFS API manager. For example, the Command parameter of the Execute function may have a value for a bill dispenser:
WFS_CMD_CDM_DISPENSE (collection of money from cassettes)
WFS_CMD_CDM_PRESENT (delivery of a packet to a client)
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) written in c ++ and theoretically libraries of service providers written for one manager should also be suitable for everyone else, but in fact, sometimes a library written by a specific vendor for a specific XFS manager only works with this manager.
There is also Java XFS with its own libraries that are not compatible with classic managers.
A 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 in the case of hardware (XFS), there are industry protocols ( NDC / DDC ) by 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 an alternative software on the market that meets all standards and is not tied to a specific vendor.
I will describe the 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.
At each point in time, the ATM is in one of the operating modes:
In service mode ATM is in one of states ( State ), numbered 001 to 999, and 25-character string description.
The first character of this line is the type of state (indicated by the letters A..Z and also a..z and some characters (, '.?)), It defines the population. The remaining 24 characters are 8 decimal 3-digit numbers, each of which is a specific state setting (screen number for display, conditions for switching to the state, list of actions). There can be any number of states of one type.
When the service mode starts, the ATM automatically starts to execute state 000. Usually this is state A (Card read state). In this mode, the ATM displays a screen prompting you to insert a card and puts the card reader in receive mode. The state is also responsible for reading the map and branching, depending on the results of this operation.
Below is an example of a typical state A configuration:
000 A001001011008004002001104
000 - state number
A - state type (Card read state)
001 - screen number (Screen number)
001 - state number to go to if the card is successfully read
011 - state number to which pass in case of card reading errors
008 - reading condition 1
004 - reading condition 2
002 - reading condition 3
001 - condition for returning the card (immediately after reading or upon completion of the operation)
104 - state of transition, if the card is unknown to the bank
Let's go through the parameters in more detail:
Type of state - everything is clear: determining the type of state , the application knows how to interpret further parameters.
Screen number - is a link to a line with a text description of the screen displayed during the operation of this state.
Not every state has a screen.
A screen can have a number from 000 to 999. Screens that differ by 100 are usually reserved for different languages. Thus, screen 010 and screen 210 are most likely multilingual versions of a single screen. I’ll talk about screens a bit later.
The number of the transition state in case of successful reading of the card is which state the application will start to execute if the card is recognized and the data has been read successfully.
In addition to the states and screens in the ATM, there is another important configuration parameter - 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, and what to do next depending on these data. For example, if the card is local, then you can run one scenario, if the card is a third-party bank, then you need to prohibit the scenario branch with mobile payments and checking the balance.
Transition state number in case of card reading problems- if the card could not be read according to any of the proposed conditions, we go to the state indicated in this parameter. As a rule, this is the state J (Close state) on which we give out the card, show a screen with a proposal to pick it up and activate the timer after which the card holding mechanism will be launched. State J is also the last state in the event of a successful transaction.
Card reading conditions (3 parameters in a row) are bit masks that indicate the numbers of tracks that need to be read, and interaction with the chip, if available.
For example, Read Chip, Read Track 2 and Track 1, Read Track 1. If at least one of the conditions works, then the other conditions are not met and the card is considered read. If none of the conditions is met, the card is considered unread.
Card return condition - the ATM can return the cards immediately after reading it, or it can do it at the end after completion of all operations.
The remaining states are arranged in a similar way:
Passing through all these states , the application sooner or later reaches the state of interaction with the host - state I (Transaction Request State). On this story, a request is formed from the data collected on past states and sent to the server. The request is an ATM ID (Logical Unit Number), data from the card's tracks, data on previous transactions, data from the amount buffers, pin block, function key presses (FDK buffer). Data is separated by a delimiter character. The server application receives the request and analyzes the FDK buffer - it is from the contents of this buffer that the host understands what the ATM wants. Then, depending on the decision made, it sends a response that contains:
In a special buffer, the number of bills to be dispensed from each cassette is transmitted (if this is a cash withdrawal operation). It is the number of notes, because the ATM does not know the face value of the money issued for it, it's 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 already known to us state J. In case of any failure, the application sends a failure message to the host and waits for a new Transaction Reply with the transition to a new state.
The ATM screen is a 32x16 cell field. The screen can contain both graphic information and text information, which is positioned relative to the cells. Fonts can be double height.
The screen description is a line of text interspersed with controlled characters, such as clearing the screen, positioning the cursor, and font size. In most modern banks, today the text is used only when entering amounts, and in other cases the screen is just a whole picture. However, there are also fully text screens.
An example of a screen displaying a picture from a table of pictures (\ 0c \ 1bP2018 \ 1b \ 5c)
It is these screens that are referenced by the state parameters.
The set of states, screens, FIT, timers is called an ATM script. Each script 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 should be updated, the host puts the ATM into the Out Of Service mode and starts loading the necessary parameters of the new configuration. The last parameter is the configuration number. Similarly, the keys are downloaded for encryption of the pin block, for mocking, and master keys.
Now, in short, this is how the ATM is arranged. I hope someone comes in with this information.
What is an ATM?
Any ATM is essentially a computer with peripherals connected, an equipment manager and the actual banking application that manages this entire economy. All decisions on issuing money are made by the server. The ATM only collects information from the client and transfers it to the server.
ATM cash
The minimum set of ATM iron includes:
- card reader for reading a client 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 add-ons connected to the pin pad. In some modern ATMs, they were replaced by a touch screen.
- money dispenser
- various sensors, backlight
Who runs this whole zoo?
In order to prevent manufacturers from writing drivers that no one needs then, 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.
So the CEN / XFS standard appeared, or simply XFS , 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 “service provider” standard, it is a library that provides a certain set of functions for receiving information about the device and managing it. Usually this 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 equipment occurs through the XFS API manager. For example, the Command parameter of the Execute function may have a value for a bill dispenser:
WFS_CMD_CDM_DISPENSE (collection of money from cassettes)
WFS_CMD_CDM_PRESENT (delivery of a packet to a client)
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) written in c ++ and theoretically libraries of service providers written for one manager should also be suitable for everyone else, but in fact, sometimes a library written by a specific vendor for a specific XFS manager only works with this manager.
There is also Java XFS with its own libraries that are not compatible with classic managers.
Banking application
A 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 in the case of hardware (XFS), there are industry protocols ( NDC / DDC ) by 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 an alternative software on the market that meets all standards and is not tied to a specific vendor.
I will describe the 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 point in time, the ATM is in one of the operating modes:
- Power Up - Download
- Offline - No connection to the server, connect
- Supervisor - a collector or service engineer works
- Out of service - the ATM does not work, because it is faulty, the money has run out, or just someone in the bank has transferred it to this mode.
- In service - the main mode of operation, familiar to all those who have bank cards.
In service mode ATM is in one of states ( State ), numbered 001 to 999, and 25-character string description.
The first character of this line is the type of state (indicated by the letters A..Z and also a..z and some characters (, '.?)), It defines the population. The remaining 24 characters are 8 decimal 3-digit numbers, each of which is a specific state setting (screen number for display, conditions for switching to the state, list of actions). There can be any number of states of one type.
In service mode
When the service mode starts, the ATM automatically starts to execute state 000. Usually this is state A (Card read state). In this mode, the ATM displays a screen prompting you to insert a card and puts the card reader in receive mode. The state is also responsible for reading the map and branching, depending on the results of this operation.
Below is an example of a typical state A configuration:
000 A001001011008004002001104
000 - state number
A - state type (Card read state)
001 - screen number (Screen number)
001 - state number to go to if the card is successfully read
011 - state number to which pass in case of card reading errors
008 - reading condition 1
004 - reading condition 2
002 - reading condition 3
001 - condition for returning the card (immediately after reading or upon completion of the operation)
104 - state of transition, if the card is unknown to the bank
Let's go through the parameters in more detail:
Type of state - everything is clear: determining the type of state , the application knows how to interpret further parameters.
Screen number - is a link to a line with a text description of the screen displayed during the operation of this state.
Not every state has a screen.
A screen can have a number from 000 to 999. Screens that differ by 100 are usually reserved for different languages. Thus, screen 010 and screen 210 are most likely multilingual versions of a single screen. I’ll talk about screens a bit later.
The number of the transition state in case of successful reading of the card is which state the application will start to execute if the card is recognized and the data has been read successfully.
In addition to the states and screens in the ATM, there is another important configuration parameter - 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, and what to do next depending on these data. For example, if the card is local, then you can run one scenario, if the card is a third-party bank, then you need to prohibit the scenario branch with mobile payments and checking the balance.
Transition state number in case of card reading problems- if the card could not be read according to any of the proposed conditions, we go to the state indicated in this parameter. As a rule, this is the state J (Close state) on which we give out the card, show a screen with a proposal to pick it up and activate the timer after which the card holding mechanism will be launched. State J is also the last state in the event of a successful transaction.
Card reading conditions (3 parameters in a row) are bit masks that indicate the numbers of tracks that need to be read, and interaction with the chip, if available.
For example, Read Chip, Read Track 2 and Track 1, Read Track 1. If at least one of the conditions works, then the other conditions are not met and the card is considered read. If none of the conditions is met, the card is considered unread.
Card return condition - the ATM can return the cards immediately after reading it, or it can do it at the end after completion of all operations.
The remaining states are arranged in a similar way:
- There are states for reading the amount from the keyboard and putting it in a special internal buffer;
- There are states for reading a pin-code with a pin-pad and then receiving a pin-block in a special buffer;
- There are states for checking the entered data (for example, if the entered amount is less than the minimum amount, then there is a redirect to the state with an error message);
- There are states for selecting with 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 preset buffers.
Passing through all these states , the application sooner or later reaches the state of interaction with the host - state I (Transaction Request State). On this story, a request is formed from the data collected on past states and sent to the server. The request is an ATM ID (Logical Unit Number), data from the card's tracks, data on previous transactions, data from the amount buffers, pin block, function key presses (FDK buffer). Data is separated by a delimiter character. The server application receives the request and analyzes the FDK buffer - it is from the contents of this buffer that the host understands what the ATM wants. Then, depending on the decision made, it sends a response that contains:
- identifier of the action to be performed;
- the number of the screen 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 at the end of the action.
In a special buffer, the number of bills to be dispensed from each cassette is transmitted (if this is a cash withdrawal operation). It is the number of notes, because the ATM does not know the face value of the money issued for it, it's 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 already known to us state J. In case of any failure, the application sends a failure message to the host and waits for a new Transaction Reply with the transition to a new state.
Now about the screens
The ATM screen is a 32x16 cell field. The screen can contain both graphic information and text information, which is positioned relative to the cells. Fonts can be double height.
The screen description is a line of text interspersed with controlled characters, such as clearing the screen, positioning the cursor, and font size. In most modern banks, today the text is used only when entering amounts, and in other cases the screen is just a whole picture. However, there are also fully text screens.
An example of a screen displaying a picture from a table of pictures (\ 0c \ 1bP2018 \ 1b \ 5c)
It is these screens that are referenced by the state parameters.
The set of states, screens, FIT, timers is called an ATM script. Each script 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 should be updated, the host puts the ATM into the Out Of Service mode and starts loading the necessary parameters of the new configuration. The last parameter is the configuration number. Similarly, the keys are downloaded for encryption of the pin block, for mocking, and master keys.
Now, in short, this is how the ATM is arranged. I hope someone comes in with this information.
