The words used around XFS and XFS4IoT, each explained in a few lines. A tag says whether a term belongs to XFS 3.x, to XFS4IoT or to both. Where part 1 of the standard deals with a term, the entry names the chapter and page in the 3.50 edition.
The C functions an application calls in XFS 3.x: WFSStartUp, WFSOpen, WFSGetInfo, WFSExecute, WFSRegister, WFSClose and the rest. Part 1 defines them; the device parts define what travels through them.
Part 1, chapter 5 “Application Programming Interface (API) Functions”, page 45.
The program that runs the machine: the screens, the transactions, the connection to the bank's host. It speaks XFS and nothing vendor-specific, which is the point of the standard.
On this site: The parts of an XFS system.
Most XFS 3.x functions exist in two forms. The synchronous one returns when the work is done. The asynchronous one (WFSAsyncExecute and the like) returns at once and the result arrives later as a Windows message, so the application is not blocked while a printer prints.
Part 1, chapter 4.3 “Asynchronous, Synchronous and Immediate Functions”, page 22.
What a device can do: which media a printer takes, which card technologies a reader has, how many cassettes a dispenser holds. An application reads them once and adapts. In XFS 3.x it is a WFS_INF_…_CAPABILITIES query; in XFS4IoT a Capabilities command on each service.
The European Committee for Standardization, the body under which the XFS Workshop meets and which publishes the XFS documents as CEN Workshop Agreements.
On this site: Sources.
An open group of companies and other interested parties that meets under CEN to produce a CEN Workshop Agreement. The XFS Workshop was opened by a public call in 1998 and has met since; its participants are named in each document's foreword.
On this site: Who is involved.
An instruction that makes a device do something: print a receipt, dispense notes, read a card. In XFS 3.x a command is a WFS_CMD_… code sent with WFSExecute. In XFS4IoT it is a JSON message named after the service and the action, such as CardReader.ReadRawData, answered by a completion.
The reply that ends a command: whether it succeeded, the error if not, and the data it produced. In XFS 3.x a completion message follows an asynchronous command; in XFS4IoT every command gets a completion message.
One piece of hardware that offers more than one device class, for example a cash recycler that is both a cash dispenser (CDM) and a cash-in module (CIM). Part 1 says how such a device appears to applications.
Part 1, chapter 4.8.2 “Compound Devices”, page 32.
The settings the XFS manager reads to know which service providers are installed and which logical service name maps to which of them. In XFS 3.x it lives in the Windows registry.
Part 1, chapter 4.7 “Configuration Information”, page 27.
The kind of document CEN publishes for XFS: an agreement reached in a Workshop, quicker to produce and to revise than a European Standard. XFS 2.00 to 3.50 are CWA 13449, 14050, 15748, 16374 and 16926; XFS4IoT is CWA 17852.
On this site: The editions.
One kind of device with its own part of the standard and its own queries, commands and events: printer, cash dispenser, card reader and so on. XFS 3.50 has 17 of them, each known by a three-letter code.
Part 1, chapter 3.3 “Device Classes”, page 17.
On this site: The device classes.
One complete set of XFS 3.x parts published together under one release number (3.50) and one CWA number. This site calls them editions; the documents say release.
On this site: The editions.
A protection added in the later editions for commands that move value, dispensing above all. The application fetches a nonce from the device and sends the command with a token the bank's host has signed over that nonce, so the device can check that the command came from the authorised host and is not a replay.
Part 1, chapter 12.2 “Determining Specific E2E Authentication Requirements”, page 136.
The result of a function or command when it did not succeed. In XFS 3.x part 1 defines the generic codes (WFS_ERR_INVALID_HSERVICE, WFS_ERR_TIMEOUT…) and each device part adds its own (WFS_ERR_PTR_NOMEDIAPRESENT…). In XFS4IoT the completion carries a completion code and an error code.
Part 1, chapter 11 “Error Codes”, page 133.
Something a device reports on its own rather than as the reply to a command. XFS 3.x has four kinds: service events (a state change, such as media taken), execute events (something that happens during a command, such as a card inserted), user events (the operator is needed, such as toner low) and system events (a hardware error, a device locked by another application). An application subscribes to them with WFSRegister. XFS4IoT has unsolicited events and events sent during a command.
Part 1, chapter 14.1 “Event and System Management”, page 157.
In XFS 3.x an application can lock a service with WFSLock so that no other application uses the device until WFSUnlock. A dispenser is locked while a withdrawal runs.
Part 1, chapter 4.8 “Exclusive Service and Device Access”, page 31.
A named layout for a printer: the fields on a receipt, statement or passbook page and where they go. The application prints by naming a form and supplying the field values; the form definitions are the printer part's own small language.
On this site: The printer class.
The C header that closes each XFS 3.x part (xfsapi.h, xfsptr.h, xfscdm.h…) with the constants, structures and message codes of that class. It is the contract a programmer compiles against.
The name an XFS 3.x application opens with WFSOpen. The configuration maps it to one service provider and one device, so the application names a role (the receipt printer) rather than a product.
Part 1, chapter 4.5 “Opening a Session”, page 25.
From edition 3.40 on, each part is accompanied by a document that lists the changes from the previous edition, so an implementer moving from 3.40 to 3.50 can see what moved.
On this site: The editions.
One document of an edition. Part 1 is the programming interface itself (API and SPI); the following parts cover one device class each. A part is cited as the CWA number and the part number, CWA 16926-3 for the printer part of 3.50.
On this site: The editions.
A request that reads from a device without changing it: its status, its capabilities, the forms a printer knows. In XFS 3.x a query is a WFS_INF_… code sent with WFSGetInfo. XFS4IoT has no separate query function; status and capabilities are commands like any other.
In XFS4IoT, one device offered over the network: a WebSocket endpoint that accepts the commands of its device class and sends its events. The service plays the role the service provider plays in XFS 3.x, without the XFS manager in between.
On this site: XFS 3.x and XFS4IoT.
The software, written by the device's manufacturer, that implements one device class on one device. The XFS manager calls it through the SPI; it drives the hardware. One per device.
On this site: The parts of an XFS system.
In XFS4IoT, the endpoint on a machine that lists the services available there with their addresses. An application connects to the publisher on its well-known port first and learns where the card reader, the dispenser and the printer are.
On this site: XFS 3.x and XFS4IoT.
An XFS 3.x application's connection to one service, from WFSOpen to WFSClose. Before any session the application connects to the XFS manager with WFSStartUp and agrees on a version; WFSCleanUp ends that.
Part 1, chapter 4.5 “Opening a Session”, page 25.
The C functions the XFS manager calls on a service provider (WFPOpen, WFPGetInfo, WFPExecute…): the API seen from the other side. A service provider implements the SPI; an application never calls it directly.
Part 1, chapter 6 “Service Provider Interface (SPI) Functions”, page 86.
The current state of a device: online or offline, busy, media present, a door open, a cassette low. Read with a query in XFS 3.x and a Status command in XFS4IoT, and changed by events in between.
A state of the machine in which the manufacturer's own maintenance software uses the devices instead of the application, for example while an engineer replenishes cash. The VDM device class switches the machine in and out of it.
On this site: The vendor dependent mode class.
The connection XFS4IoT uses: a long-lived channel over TLS on which both sides send messages at any time. Commands, completions and events are JSON texts on that channel.
On this site: XFS 3.x and XFS4IoT.
Windows Open Services Architecture, eXtensions for Financial Services: the name of the standard before it moved to CEN in 1998, when it was written by the Banking Solutions Vendor Council with Microsoft for the Windows PCs that were replacing proprietary ATM controllers.
On this site: A short history.
The first generation of the CEN standard as a C interface on one Windows PC: editions 3.00 (2000) to 3.50 (2022), preceded by 2.00 (1998). Still running in most machines in the field.
On this site: The editions.
The thin layer in XFS 3.x between the application and the service providers. It routes each call to the right service provider, keeps the rules of the conversation (versions, timeouts, locks, event registration) and there is one per machine.
Part 1, chapter 3.1 “Architecture”, page 13.
On this site: The parts of an XFS system.
The current generation, published since 2021 as CWA 17852: the same roles and device classes as XFS 3.x, expressed as JSON messages over WebSocket, independent of the operating system and of where the application runs.
On this site: XFS 3.x and XFS4IoT.
The definitions are this site's wording, written to be short. The standard's own text is normative; where the two differ, the document is right. The device-class codes (PTR, CDM, IDC…) are explained in the class table, each with its own page.