Xolutiva CEMI.ai
Español

To coordinate with Xolutiva and NCR Atleos

NDC Enterprise: from demos to real transactions

1 October 2026 CEMI · ibizai Findings, questions and plan

The applications we have shown on the ATM are HTML demos. We want to take the next step with you: real transactions on NDC Enterprise, starting in the lab. This page gathers what we found, what we need to ask and how we propose to move forward.

Video: NDC Enterprise, by NCR Atleos, presented by Xolutiva (2:25, in Spanish with captions).

01 · Where we are

Demos that run on the ATM without touching its devices

They run in the web layer of the lab’s SelfServ 62. They show the whole experience, but they do not print, count cash, read cards, or talk to NDC Enterprise or to a host.

02 · What we want to achieve

Real applications: printer, cash and cards, through NDC Enterprise

First lab goal

One adjunct non-cash transaction, end to end: for example, an enquiry that prints a real receipt.

Second lab goal

One cash transaction: a deposit counted by the machine, with its receipt and its reversal if something fails.

All in the lab, with a test image, test host, test cards and test cassettes. Nothing in production until the bank, NCR Atleos and the acquirer approve it.

03 · What we found

Half of the knowledge is public; you and NCR hold the other half

VerifiedOur inferenceTo confirm
Verified

The device layer is an open standard

Printer, cash, card reader, PIN pad and sensors are exposed through CEN/XFS 3.x (a Windows API) and its successor XFS4IoT (WebSocket and JSON), both published by CEN free of charge. NCR Atleos is named among the organisations that developed XFS4IoT.

Verified

There is an open simulator to start with today

An MIT-licensed XFS4IoT framework exists with sample device services (card reader, dispenser, acceptor, recycler, printer, PIN pad, lights, barcode, camera) that runs on a Windows computer.

Verified

What NCR Atleos says about NDC Enterprise

It is multi-vendor; it "removes the need for switch changes by adding adjunct digital transactions that can utilize a connection to core banking or third-party partners"; screens and segmentation are changed from an enterprise server; over 100 banking services.

To confirm

The NDC Enterprise layer is not public

We found no public documentation on how adjunct transactions are authored, which engine renders the web layer, how web content asks a device for an action, or how a flow hands the final transaction to the switch. That can only come from NCR Atleos, through Xolutiva.

Our inference

Our code would run inside NCR’s application, not beside it

On a bank ATM, NCR’s application owns the devices. The PIN is captured in the encrypting PIN pad, the EMV kernel belongs to the platform, and software whitelisting is controlled by the bank and NCR. The open simulator is for learning and for proving our abstraction layer; the production adapter will be written against whatever interface NCR provides.

04 · What we need

What only Xolutiva and NCR Atleos can give us

WhatWhat for
NDC Enterprise developer documentation and its authoring kit or toolWith a licence that covers an outside developer
The reference for the interface web content uses to reach devicesPrint, accept and dispense cash, read a card, guide lights, events and errors
An NDC Enterprise simulator and a host simulator, if they existTo develop without tying up the machine
On the lab ATMs: a test image, supervisor access, test cassettes, test cards and test keysThe machines are already in the lab; they need to be put in test mode
A test host to connect the ATM toFor the financial leg of a transaction
Access to the NCR Atleos portal and a technical contact for developmentDocumentation, downloads and support
Training or certification, if NCR requires itWhich one, how long and how many people

05 · Questions

The questions, by topic

Please answer what you can and pass the rest to NCR Atleos. Whatever we receive under confidentiality stays under confidentiality.

A. The equipment we have today
  1. On the lab ATMs, which devices are fitted? (card reader and type, contactless reader, encrypting PIN pad, receipt and journal printers, recycler and cassettes, barcode, fingerprint, cameras, upper screen).
  2. Today our demos run in a "web layer" on the ATM. What exactly is it: a browser in kiosk mode, or a container belonging to NCR’s application? Which engine and version?
  3. Which operating system and which NCR XFS platform do the machines run? Which ATM application is installed today (NDC Enterprise, Activate Enterprise, ANDC or another), and in which version?
  4. Do NCR Atleos machines expose, or plan to expose, XFS4IoT services, or only CEN/XFS 3.x? On what timeline?
B. Documentation and development kit
  1. Is there official, current NDC Enterprise documentation for developers? Can you share it with us under a confidentiality agreement?
  2. Which tool is used to create adjunct digital transactions, screens and flows? Which technologies and versions does it require?
  3. Who may develop on NDC Enterprise: only NCR, the bank, the certified partner, or also a partner’s subcontractor such as CEMI? Which licence is needed and what does it cost?
  4. Does the confidentiality agreement allow us to use AI assistants to read that documentation while we develop? If there are restrictions, which?
C. How it works inside
  1. How does web content request a device action, and how does it receive events and errors? Is there a reference for that interface?
  2. What is the enterprise server and where does it run: at the bank, in NCR’s cloud, or both? How are screens and flows published to the ATMs?
  3. How does an adjunct flow hand the final financial transaction to the switch? Which part of the flow remains classic NDC?
  4. Which card and customer data can web content see? Does it receive an identifier instead of the card number? How is the customer identified in a cardless transaction?
  5. How does a flow connect to the core banking system or to a third party: from the ATM or from the server?
  6. We confirm our understanding: the PIN is always captured in the encrypting PIN pad and our code never sees it. Is that correct? How does a flow request PIN entry?
D. Simulators and lab
  1. Is there an NDC Enterprise simulator for developing without the ATM, and a host or switch simulator? Under which licence?
  2. What does it take to put the lab ATMs on a test image, with supervisor access, test cassettes, test cards and test keys? With what technical support from Xolutiva?
  3. Which test host would they connect to?
E. Security and deployment
  1. Which logical security controls will the lab and production machines have (whitelisting, hardening, disk encryption, firewall, dispenser protection)? What must we comply with for our content to be installable?
  2. Which outbound connections are allowed from the ATM, and which must go through the server?
  3. How is third-party content signed, packaged and authorised before installation? Who signs it?
  4. Is there NCR guidance on what an outside developer must never do on the ATM?
F. Certification, support and terms
  1. Does NCR Atleos require training or certification to develop or deploy on NDC Enterprise? Which, how long, at what cost and for how many people?
  2. Which tests or certifications does a new transaction need before production: from NCR, the bank, the switch, the local network, the card brands?
  3. Is NDC Enterprise validated under the PCI Secure Software Standard? Does third-party content fall inside or outside that validation?
  4. Which changes force EMV recertification with the acquirer or the brands?
  5. Who is our technical contact at NCR Atleos, and can we have access to the portal and to support through Xolutiva?
  6. What is Xolutiva’s tier in the NCR Atleos channel programme, and what does it allow sharing with a subcontractor?
  7. What timelines and costs should we expect to receive the documentation and the kit, and to complete a first test transaction?

06 · The plan

Four phases: two we can start today

A

Abstraction layer

One interface for devices and for the host, with a simulated adapter. The demos keep working as they do and can inject faults: out of paper, empty cassette, timeout.

Who: CEMI, starting now · Needs: Nothing
B

Open simulator

XFS4IoT client and a mock host. The same flow passes the same automated tests against the simulated adapter and against the simulator.

Who: CEMI, starting now · Needs: Nothing
C

Lab integration

With NCR’s kit and documentation: the NDC Enterprise adapter, on the lab ATM in test mode and against a test host. Goal: one adjunct non-cash transaction and one cash transaction, end to end.

Who: CEMI, Xolutiva and NCR Atleos · Needs: Everything under "What we need"
D

Pilot with a bank

The bank’s security review, testing, whichever certifications apply, signed packages and a controlled rollout to a few machines.

Who: Bank, NCR Atleos and Xolutiva; CEMI as supplier · Needs: Contractual and compliance framework

07 · The first two weeks

What we do while the answers arrive

Week 1

  • Send the questions to Xolutiva and open a private repository for this work.
  • Define the device and host interface, with its result and fault model.
  • Route one real flow through that interface: the cash deposit with a printed receipt.
  • Build and run the open simulator on Windows and record its messages.

Week 2

  • XFS4IoT client: discovery, commands, events, cancellation and reconnection.
  • Mock host: approve, decline, timeout, late reply and reversal.
  • Failure matrix: what the customer sees and what is reversed at each step. It is the first thing a bank will ask for.
  • Review Xolutiva’s answers and decide on moving to lab integration.

08 · Security

What we will never do, from demo to production

  • Never capture, display, log or transmit a real PIN. PIN entry belongs to the encrypting PIN pad.
  • Never read or store full card numbers, track data or chip data in our code, logs or screenshots.
  • Never handle cryptographic keys or key-loading procedures.
  • Never run our code on an ATM connected to a production host or loaded with real cash. Lab only: test image, test host, test cards and test cassettes.
  • Never disable or relax whitelisting, the firewall, encryption or dispenser protection to make a demo work.
  • Never issue device commands outside the ATM application’s sanctioned interface.
  • Never commit vendor kits, documentation under confidentiality, certificates, keys, bank configuration or customer data to a repository.
  • Never test with real cards or accounts, including the team’s own.
  • Never load remote scripts, fonts, analytics or tags on the ATM: everything is packaged, versioned and reviewed.
  • Never tell a bank that something is ready for production before the bank, the vendor and the acquirer have signed off their part.

09 · Next steps

What we ask of you today

  1. Confirm what the web layer that runs today’s demos is, and which ATM application the lab machines carry.
  2. A technical contact for development at NCR Atleos, and portal access through Xolutiva.
  3. The NDC Enterprise developer documentation and its kit, under a confidentiality agreement.
  4. Set one lab ATM up with a test image, supervisor access and a test host.
  5. Choose the first real lab transaction together and give it a date.

Prepared by CEMI for Xolutiva. The findings come from public sources consulted on 1 October 2026 (CEN, PCI SSC, NCR Atleos); anything marked "to confirm" could not be verified and is put as a question. Working page, not indexed. business@cemi.ai