2011

APTRA: History and

Structure of NDC

Are you involved in selling or supporting ATMs? Do you know how NDC works? Do you 
know what a State Table is? What gets downloaded to the ATM? 
My name is Colin Davis, and in this seminar, I will give you a short history of ATMs, and 
then describe what is meant by the NDC environment.

1
 Objectives

•Discuss the history of NDC

• List the tables contained in a Downline Load
• Describe the content of those tables
• Describe State Processing
• Describe the NDC Transaction Flow
• List the Operational Modes

NCR Confidential 2

By the end of this seminar, you should be able to: 
Describe the development of NDC, list the tables contained in a Downline Load, describe 
the content of those tables, describe (at a high level) State Processing, the flow of 
transactions and list the operational modes. 
In this seminar we will look briefly at the history of ATMs since the first one was 
installed. Then we will get into NDC and see how it operates with the various tables that 
get downloaded. 
We will look at the types of message that get passed between the terminal and the host 
and we will list the operational states that the terminal can be in. 
 ATM Timeline (1967 - 1974)

• Docutel enjoys 100% of market with 2900 units

• 1967 Barclays Bank installed the world’s first ATM
• 1969 Docutel installs the first U.S. made cash dispenser
in Chemical Bank of New York
• 1971 Citizens and Southern National Bank of Atlanta
installs the first U.S. full function ATM by Docutel
• 1974 ATM installations still only on premise. Available
ATMs include Diebold 5000, IBM 3614 and NCR 770

NCR Confidential 3

As you can see from the ATM Timeline here, the first ATM that was installed was at 
Barclay’s Bank in the UK in 1967. At that time, Docutel was the only ATM manufacturer. 
Docutel then moved to the North American market, Chemical Bank in 1969, and then on 
to Citizen’s and Southern National Bank of Atlanta in 1971. 
As of 1974, Docutel enjoyed 100% of the market, but with only 2900 units. 
ATM installations were limited to on‐premise only, the off‐premise market had not been 
conceived. 
This is where NCR entered the market, with our 1st generation ATM, the NCR 770. 
 ATM Timeline (1977 - 1979)

• ATM market gains momentum

• New products are announced:
• Diebold 9000 - Controller Based
• IBM 3624 - Couldn’t deliver for 18 months
• Docutel 2000 - Unreliable, expensive & difficult upgrade path
• NCR 1770 in-lobby ATM – Ahead of its time, but delivery is
1978 and software is poor
• 1979 NCR releases the 1780
• IBM delivers 3624 in quantity.
• Diebold releases the 910 Direct Connect.
• Docutel releases a new T-2300 with retrofit for 300 users

NCR Confidential 4

In 1977, the ATM market really started to gain momentum. Diebold had its 9000 
controller based solution, IBM had announced its 3624 but they couldn’t deliver for 18 
months. 
Docutel 2000 units were unreliable and expensive to upgrade and the NCR 1770 in‐
lobby ATM could not be delivered until 1978. 
The 1770 was NCR’s second generation ATM and it is important to note that Diebold
was the only ATM vendor at the time that was able to deliver units, and so consequently 
they grew their market share to number 1. 
In 1979, NCR did come out with the 1780 which unfortunately had some reliability 
problems. IBM were able to deliver their 3624, and Diebold started to release the 910 
direct connect software. 
 ATM Timeline (1982 - 1990)

• More companies join the growing market

• TRW/Fujitsu
• Burroughs
• 1983 NCR 3rd Generation (50xx series) launched
• NCR Direct Connect (NDC) software created
• Either Diebold Emulation (to capture replacement business)
• Or NCR Native to take advantage of NCR features
• 1990 NCR 4th Generation launched
• NDC+ created to support 4th Generation features. NDC+
uses the same host application and NDC and the same
customisation data
• Operating system is OS/2

NCR Confidential 5

In 1982 more companies joined the growing market with Fujitsu and Burroughs and 
then in 1983, NCR really came on board with its third generation and the creation of a 
dedicated Self‐Service Business Unit. 
Also in 1983 NCR Direct Connect software was created to operate its 3rd Generation, 
50xx series, either in Diebold emulation to capture replacement business, or in NCR 
Native mode to take advantage of NCR features such as having 8 Function Display Keys. 
In 1990, NCR’s 4th generation was launched and at that time the original NDC software 
was migrated to NDC+ that was created specifically to support 4th generation features 
such as the ability to display graphic images, rather than just text. 
Crucially NDC+ used the same host application as NDC and the same customisation data. 
Being backwards compatible, so that new software can be installed with ‘no host 
change’, is a guiding principle for many of our customers even today.
 ATM Timeline (1996 - 2002)

• NCR Personas Series launched

• NCR first hardware capable of supporting Windows NT
• Self Service Development System (SSDS)
• Can still run NDC+ with OS/2
• 1998 SSDS-NDC launched for NT Operating System
• 1999 NCR Self-Service Software re-branded as APTRA
• APTRA Advance NDC
• 2002 APTRA software now supports Windows XP

NCR Confidential 6

In 1996, NCR launched our Personas series. Personas was the first hardware Platform 
from NCR that was capable of supporting the Windows NT operating system. 
At the same time we also launched SSDS which is an application development 
environment but critically the Personas supported the older NDC+ application running 
with the older OS/2 operating system as well. 
So it was ideal to provide a migration path to go from OS/2 to Windows NT and 
eventually Windows XP. 
In 1998, SSDS NDC was launched to operate with the NT operating system and in 1999, 
NCR re‐branded its Windows based software to the APTRA software suite. 
In 2002, the APTRA software was migrated to run on both Windows NT and Windows 
XP.
 ATM Timeline (2005 - 2011)

• Multi-Vendor becomes the key word

• CEN XFS
• 2005 APTRA Advance NDC 3.0
• Full multi-vendor support
• 2008 NCR SelfServ series launched
• Replacement for Personas range
• Move from Serial devices to USB
• 2011 APTRA Advance NDC 4.1
• Windows 7 supported
• Multi-vendor enhancements for Cash In

NCR Confidential 7

One of the key drivers in the last few years has been the move to providing 1 software 
solution that will work on terminals from all the major manufacturers.  Banks 
increasingly want to buy the hardware from any supplier but still be able to run, and 
support, software from just 1 supplier regardless of the hardware.
All of the major manufacturers, including NCR, got together with CEN, the European 
Committee for Standardisation, to produce a standard called CEN XFS that would help 
software developers to write 1 application that would run on any CEN XFS compliant 
system.
APTRA Advance NDC version 3.0 was released in 2005 that would work not only on NCR 
ATMs, but also Diebold, Wincor and in theory, any CEN XFS compliant hardware.
In 2008 NCR replaced the Personas range with the updated SelfServ range of hardware, 
increasing the variety of devices, such as deposit devices, as well as moving from older 
Serial based hardware to USB devices.
In 2011 NCR started limited support for Windows 7 on a select number of SelfServ 
terminals, with the intention of full Windows 7 support by the end of 2011.  APTRA 
Advance NDC version 4.1 is the first version of NDC to support Windows 7 as well as 
having major enhancements for Deposit solutions.
 ATM SW Architectures in 1980s

• More History
• With the launch of the 3rd Generation there were three
types of ATM system architectures
• The primary difference between the architectures was the
location of transaction processing:
• Direct Connect
• Controller Based
• Intelligent ATM
• The rest of this presentation will focus on the Direct
Connect system architecture

NCR Confidential 8

That was a brief history of ATM hardware, now we will concentrate on the APTRA 
software products that NCR sell that are suitable in the NDC environment. 
With the launch of NCR’s 3rd generation ATM in 1983 there were a number of ATM 
system architectures in use at the time. 
The primary difference between the architectures was the location of the transaction 
processing capabilities. You’ve got to remember this is the early 80s, personal 
computers were in their infancy, most computers were Main Frames where all of the 
processing is done on 1 large central system and all of the terminals are dumb. But the 
80s saw the introduction of micro‐processors that could make more and more 
processing decisions locally, only needing a central computer for the final authorisation.
Diebold’s 910 Direct Connect software had started a trend where all of the functionality 
was centrally managed by the Bank’s mainframe computer. 
Alternatively there was a controller based solution, and Intelligent ATMs where the 
ATMs were able to make a lot of decisions at the terminal level.
NCR’s Direct Connect software was produced, initially to be compatible with the Diebold 
910 Direct Connect, but then it branched out to become its own standard, NDC, to 
support the features of NCR hardware.
 Direct Connect

• In Direct Connect systems:

• Network software designed for non-intelligent terminals
• Transaction control is at the Central Host
• If the network goes down for any reason, the ATMs are
unavailable
• Changes to terminal screens/configuration:
• Downloaded through the network from Central
• Table-driven software to all direct connect terminals
• States, Screens, FITs, Configuration

NCR Confidential 9

So what is NDC? Well with Direct Connect systems, the network is designed for non‐
intelligent terminals, it was more cost effective at the time to have lower cost terminals 
and greater central processing. 
There was nothing like the CPUs that we have now, where processing is cheap and 
efficient at the terminal level so transaction control was always at the bank’s central 
mainframe or Host. Some of the drawbacks were that if the network ever went down 
for any reason, the ATM network was also unavailable. 
The software on a Direct Connect terminal was Table Driven. What do I mean by ‘Table 
Driven Software’? 
The software on the ATM knows how to operate the hardware, but it doesn’t have any 
intelligence in terms of how to present a transaction to a cardholder, what it does is 
follow information that has been sent to it from the central host which are stored as 
tables.  
The software running on the ATM looks at the tables to tell it things like what 
information to display on the monitor, what steps need to be followed and the 
sequence of those steps to walk a cardholder through an ATM transaction. 
The tables also give the ATM information about how to process Card and PIN 
information and they have values for things like timeouts and different types of 
configuration information. 
Table information is sent to the ATM through something called the Downline load. The 
downline load is a series of messages sent to every NDC terminal from host ‐ sending 
the States, Screens, Financial Institution Tables (FITs) and Configuration tables for the 
ATM to store locally and follow.
 Advantages / Disadvantages

• Advantages
• Lower cost ATMs
• Centralised Control
• Gives networks the ability to control all ATMs centrally

• Disadvantages
• No off-line processing
• Processing load on host
• May cause overload, requiring larger or additional processors
to be used
• No local control
• Changes must be made at the Host

NCR Confidential 10

The advantage is that when the Direct Connect architecture was first launched in the 
mid 70’s and early 80’s, that it had a low cost for ATMs ‐ less intelligence was required 
at each terminal. This also allowed for centralised control ‐ one change on the bank’s 
central mainframe could then be pushed quickly to every ATM. Networks had the ability 
to control all of their terminals centrally, so they knew exactly what was going on at a 
specific ATM in any given point in time. 
The disadvantages of having no processing at the ATM is that it can not operate in off‐
line mode. 
It also creates a real processing load on the central host computer.  As more and more 
ATMs get added to the bank’s network, the Host will have capacity issues that have to 
be dealt with.  
But more than that, as ATMs handle more and more diverse types of transaction, such 
as Mobile Phone Top‐up, having 1 central Host becomes very expensive to upgrade, 
support and maintain.
And the final disadvantage with traditional Direct Connect is that there is no local 
control – the ATM is not able to make decisions, and therefore the host has to program 
all changes. 
So again, in the centralised NDC world, there is a strong dependency on host 
programming capabilities for the customer, skills that are becoming more and more 
specialised and expensive. 
To support a new transaction, they will have to go to their host software, such as ACI or 
Deluxe Data and then they are going to get in line for resource availabilities and costs. 
 Central - Host - Switch

HOST
CENTRAL

SWITCH

NCR Confidential 11

So far I have used the terms Central and Host to talk about the mainframe computer at 
the Bank.
In the early days, everything was on‐premise and the ATM only served the owning 
institution’s customers. “Central’ was the bank’s mainframe computer, also called the 
Host computer. 
Later, banks got together to form alliances where if you were a customer of 1 bank, you 
could also use the ATMs of their partners, this greatly increased the number of ATMs 
you could use as the customer of a particular bank.
Today of course you can use almost every ATM in the world and it can service almost 
any card whatsoever.
To manage these networks of interconnected systems, the ATMs are connected to a 
‘Switch’ computer, which will route authorisation requests to the appropriate host 
anywhere in the world.
So you will see the words Central, Host and Switch used almost interchangeably 
because, from the ATMs perspective, it is all the same thing. 
It talks to ‘Central’ which it believes is at the other end of that communication link.
 Table Driven Software

• Defines the “personality” of the ATM and governs

• ATM Software
• APTRA Advance NDC, APTRA Edge or APTRA Activate
• Downline Load
• States, Screens, FITs, Configuration
• Command Messages from Central
• Go In Service, Go Out of Service, Print this…

• Downline Load
• Table information sent to the ATM
• Not Software Management
• Install new software, download new graphics

NCR Confidential 12

We want to focus on NDC terminal operations and get back to some of the points that 
were raised earlier. 
Terminal operations are controlled by really three different things in the NDC world. 
They are controlled by the software running on the ATM, the customisation downline 
load from the host and finally they are controlled by command messages sent to the 
ATM again from Central.
I want to differentiate between the Downline Load and Software Management here.
The Downline Load is a series of messages from Central to the ATM containing the table 
information. Software Management or Software Distribution systems are completely 
separate.
Software Management is for installing operating system patches, new versions of 
software, new graphics files and generally controlling the software on the ATM.  
The downline load is not capable of sending a new image file to the ATM, the bank will 
have to install separate software for that.
 On Power-Up

• When an NDC ATM is powered on

• Terminal sends a status message to Central & enters Out
of Service mode
• Central may now downline load customisation data
• Central may also change encryption keys and set terminal
Date/Time
• Central sends a “Go In Service” command to the terminal

NCR Confidential 13

So as a brief overview, these are the steps that an NDC ATM may follow on power‐up. 
The first thing is to power up, check all the hardware is working, establish 
communications and send a status message Central so that is knows the ATM has just 
been turned on. 
But a traditional NDC ATM will not be available to cardholders yet, it will enter an Out of 
Service mode.
Central may choose to do a downline load of new customisation data ‐ loading any new 
State Tables, any new Screen Data, FIT tables and Configuration Parameters. 
Central may also choose to change Encryption Keys, reset the terminal’s Time and Date 
and request the status information for all of the devices fitted to the ATM. 
Once that’s done, Central will decide whether to send a Go In Service command to the 
ATM, allowing it to become available to cardholders. 
The point of this is the traditional NDC ATM really can not do anything unless the central 
host or switch says to do something.
 Customisation Data

State 0 Screen 10:

• State Tables Card Read ‘A’ State Please Insert Your Card
Screen: 10
Good Read go to 1

State 1 Screen 11:

PIN Entry ‘B’ State Please Enter you PIN
Screen: 11
Cash Withdrawal Good PIN go to 2 Cash Deposit

State 3 State 4
State 2
Amount Entry ‘F’ State Cash Deposit ‘>’ State
Menu ‘E’ State
Screen: 13 Screen: 14
Screen: 12
Go to 5 Go to 5
Balance
State 5
Trans Request ‘I’ State
Screen: 15

NCR Confidential 14

I keep mentioning States Tables, what do I mean by a State Table?
Think of the State Table as a number of sequential instructions, similar to a conventional 
computer program. 
Each state is similar to a program instruction and when the terminal is in service, the 
tables are executed the same as a program gets executed, starting at State 0 which is 
the first line of the states table. 
Most states include some sort of a screen number to display and a Next State number as 
part of the table data. So, when you are executing a state table, it says “This is what 
we’re going to do for this particular step of this transaction. You need to paint a 
particular screen on to the monitor that might have the welcome screen for example, 
enable the card reader, and when the card gets inserted, there is a new screen that gets 
painted on to the monitor.”
The state table articulates, for each step of the transaction, what to do with the 
information, what information to post on to the monitor and where to go next.
 Example State - ‘A’ Card Read

• State 0 - Card Read State, type ‘A’

• Screen to display “Please Insert Your Card”
• Where to go next after reading a card

NCR Confidential 15

Here is the beginning of the definition of the Card Read state. You can see that it begins 
with a 1 character State Type (in this case ‘A’). This state type tells the ATM software 
what hardware to enable and what data to collect.  
The A state is card read, so enable the card reader.  The F state is Amount Entry, so 
enable the number keys and allow the entry of an amount.
Each table entry has 9 parameters, I am only showing you the first 3 here. 
The first parameter is always the State Type which is just 1 character.
Each subsequent parameter is 3 characters and refers to a screen number, another state 
number or some other information that tells the ATM software how to operate in this 
particular state. 
 Transaction Processing

State 0 Screen 10:

Card Read ‘A’ State Please Insert Your Card
Screen: 10
Good Read go to 1

State 1 Screen 11:

PIN Entry ‘B’ State Please Enter you PIN
Screen: 11
Cash Withdrawal Good PIN go to 2 Cash Deposit

State 3 State 4
State 2
Amount Entry ‘F’ State Cash Deposit ‘>’ State
Menu ‘E’ State
Screen: 13 Screen: 14
Screen: 12
Go to 5 Go to 5
Balance
State 5
Trans Request ‘I’ State
Screen: 15

NCR Confidential 16

Once the ATM is told to Go In Service by Central the traditional NDC terminal will 
execute the first State table entry, state number 0.  Here I’ve shown a very simplified 
transaction flow example.
State 0 should be some sort of a Card Read state, I’ve used an A state. The software 
knows that for an A state it needs to enable the card reader and when a card is inserted, 
parameters in the A state table entry tell the software which tracks to read from the 
card. 
If the card is read successfully the NDC software will go to the state number identified 
by the State Table, in this case a PIN Entry state. 
Next my state flow goes to the main transaction menu, offering the cardholder 3 
transactions, Cash Withdrawal, Cash Deposit and Balance.  The flow branches depending 
on which option the cardholder chooses but eventually will always come back to a 
Transaction Request State, which sends a Transaction message to Central for 
authorisation.
 Transaction Request - Transaction Reply

• Central must tell the ATM what to do next

• Transaction Reply
• For example, Dispense and Print
or Display “Sorry Not Enough Funds”
• How many notes to dispense
• What to Print on what printers
• What State to go to next
• Ready Message - Sent to Central to confirm all went well
• Or Status Message - Indicating an error
• Central must send another Transaction Reply to tell the ATM
what to do next

NCR Confidential 17

Central then responds with some sort of Transaction Reply command; and this is 
important, there is a hierarchy here ‐ when the terminal is talking to the host, it is a 
request, and when the host is talking to the terminal, it is a command –
which instructs the terminal on the operation to be performed, what screen data to 
display, the data to be printed, the number of notes to dispense and the next state to 
enter. 
So the ATM gets the Transaction Reply command, and if the ATM completes the 
operation successfully, a Ready message is transmitted to Central and the next state is 
entered. 
But if there is an error, then a device status is transmitted to Central, and the terminal 
waits for another Transaction Reply command from Central. 
The ATM relies on Central to tell it what to do.
 3 Constituent Parts

• Cardholder Terminal Central

NCR Confidential 18

You can see that this transaction flow is really divided into 3 constituents that are really 
important in how an NDC transaction takes place. 
You have the Cardholder, who is obviously the customer. You have got the terminal that 
is interested in following what is going on; and then you’ve got the central application. 
Each cardholder might choose a different flow through the states by selecting different 
transaction types. So starting from state 0, “Please Insert Your Card” the card is read, 
and then the terminal goes to the next State which might say “Please Enter your PIN”. 
So the cardholder enters their PIN, “Please choose a transaction type”, “Please Enter an 
Amount” and so on.
All of that information – the card number, the PIN information, the transaction selection
and the amount all get collected before the terminal starts to talk to the host.
Only when all of the transaction information has been entered does the ATM send the 
Transaction Request message. 
The central application authorises the transaction, by making sure that the card is a valid 
card, that the PIN is a valid PIN for that card, and any other checks that it chooses to 
make, such as whether there is sufficient funds in the account. 
Once all those checks have been done and the host is satisfied that the transaction is 
legitimate, then it sends a Transaction Reply command to Dispense, Print, and then go 
on to the next state. 
 Operational Modes

• NDC terminal can operate in 7 different modes

• Start Up Mode
• Out of Service Mode
• In Service Mode
• Settlement Transaction Mode
• Offline Mode
• Supervisor Mode
• Suspend Mode

NCR Confidential 19

Finally I wanted to touch briefly on the different types of operation modes that an ATM 
can be in, in an NDC application. 
Really, there are 7 different modes. 
You have got Start‐up mode, the Out of Service mode, the In Service mode, Settlement 
Transaction mode, Offline mode, Supervisor mode and Suspend mode. 
These modes are pretty intuitive as to what goes on, but if any of you are interested in 
more detail, you could speak with your local PS consultant or drop me an email. 
 NDC Capable Software

• 3 APTRA software for an NDC environment:

• APTRA Advance NDC
• Follows traditional Host downloaded States and Screens
• APTRA Edge with an NDC Proxy
• Discontinued in 2010
• APTRA Activate
• Support for NDC messages

NCR Confidential 20

Now that you know what we mean by “the NDC environment”, let’s finish by talking 
about the NCR software specifically.
NCR have 3 APTRA software products that can be used in an NDC environment. 
APTRA Advance NDC follows the traditional NDC philosophy of a bank central computer 
controlling the customer screens and functions using States and Screens. This is the 
most traditional NDC software.
Then there was APTRA Edge with an NDC proxy but this discontinued in 2010 and 
replaced directly with APTRA Activate which also supports NDC messages.
APTRA Edge and APTRA Activate do not follow the traditional NDC state flow, and 
screen download, but they do respect the NDC messaging system so they can work with 
an NDC host. They have more independence than APTRA Advance NDC, there is more 
local ATM configuration and local processing, but the final authorisation can still be 
done using the traditional NDC Transaction Request and Reply messages.
I hope that the information that I’ve given you has provided a useful insight into the 
world of NDC and what that means to the ATM marketplace.