CWA 16926-64:2023
(Main)Extensions for Financial Services (XFS) interface specification Release 3.50 - Part 64: Cash Dispenser Module Class Interface - Programmer's Reference - Migration from Version 3.40 (CWA 16926:2020) to Version 3.50 (this CWA)
Extensions for Financial Services (XFS) interface specification Release 3.50 - Part 64: Cash Dispenser Module Class Interface - Programmer's Reference - Migration from Version 3.40 (CWA 16926:2020) to Version 3.50 (this CWA)
This specification shows the modifications made to version 3.40 of CWA 16926-5 in version 3.50.
Specifikacija vmesnika razširitev za finančne storitve (XFS), izdaja 3.50 - 64. del: Vmesnik razreda modula blagajniškega avtomata - Referenca za programerje - Prehod z različice 3.40 (CWA 16926:2020) na različico 3.50 (ta CWA)
Ta specifikacija prikazuje spremembe različice 3.40 standarda CWA 16926-5 v različici 3.50.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST CWA 16926-64:2023
01-april-2023
Specifikacija vmesnika razširitev za finančne storitve (XFS), izdaja 3.50 - 64. del:
Vmesnik razreda modula blagajniškega avtomata - Referenca za programerje -
Prehod z različice 3.40 (CWA 16926:2020) na različico 3.50 (ta CWA)
Extensions for Financial Services (XFS) interface specification Release 3.50 - Part 64:
Cash Dispenser Module Class Interface - Programmer's Reference - Migration from
Version 3.40 (CWA 16926:2020) to Version 3.50 (this CWA)
Ta slovenski standard je istoveten z: CWA 16926-64:2023
ICS:
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
35.240.15 Identifikacijske kartice. Čipne Identification cards. Chip
kartice. Biometrija cards. Biometrics
35.240.40 Uporabniške rešitve IT v IT applications in banking
bančništvu
SIST CWA 16926-64:2023 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
SIST CWA 16926-64:2023
SIST CWA 16926-64:2023
CEN
CWA 16926-64
WORKSHOP
January 2023
AGREEMENT
ICS 35.200; 35.240.15; 35.240.40
English version
Extensions for Financial Services (XFS) interface
specification Release 3.50 - Part 64: Cash Dispenser
Module Class Interface - Programmer's Reference -
Migration from Version 3.40 (CWA 16926:2020) to
Version 3.50 (this CWA)
This CEN Workshop Agreement has been drafted and approved by a Workshop of representatives of interested parties, the
constitution of which is indicated in the foreword of this Workshop Agreement.
The formal process followed by the Workshop in the development of this Workshop Agreement has been endorsed by the
National Members of CEN but neither the National Members of CEN nor the CEN-CENELEC Management Centre can be held
accountable for the technical content of this CEN Workshop Agreement or possible conflicts with standards or legislation.
This CEN Workshop Agreement can in no way be held as being an official standard developed by CEN and its Members.
This CEN Workshop Agreement is publicly available as a reference document from the CEN Members National Standard Bodies.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2023 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.
Ref. No.:CWA 16926-64:2023 E
SIST CWA 16926-64:2023
Table of Contents
European Foreword . 5
1. Introduction . 9
1.1 Background to Release 3.50 . 9
1.2 XFS Service-Specific Programming . 9
2. Cash Dispensers . 10
3. References . 11
4. Note Classification . 12
5. Info Commands . 13
5.1 WFS_INF_CDM_STATUS . 13
5.2 WFS_INF_CDM_CAPABILITIES . 18
5.3 WFS_INF_CDM_CASH_UNIT_INFO . 23
5.4 WFS_INF_CDM_TELLER_INFO . 30
5.5 WFS_INF_CDM_CURRENCY_EXP . 32
5.6 WFS_INF_CDM_MIX_TYPES . 33
5.7 WFS_INF_CDM_MIX_TABLE . 34
5.8 WFS_INF_CDM_PRESENT_STATUS. 35
5.9 WFS_INF_CDM_GET_ITEM_INFO . 37
5.10 WFS_INF_CDM_GET_BLACKLIST . 39
5.11 WFS_INF_CDM_GET_ALL_ITEMS_INFO . 40
5.12 WFS_INF_CDM_GET_CLASSIFICATION_LIST . 43
6. Execute Commands . 45
6.1 WFS_CMD_CDM_DENOMINATE . 45
6.2 WFS_CMD_CDM_DISPENSE . 48
6.3 WFS_CMD_CDM_COUNT . 52
6.4 WFS_CMD_CDM_PRESENT . 55
6.5 WFS_CMD_CDM_REJECT . 57
6.6 WFS_CMD_CDM_RETRACT . 58
6.7 WFS_CMD_CDM_OPEN_SHUTTER . 61
6.8 WFS_CMD_CDM_CLOSE_SHUTTER . 62
6.9 WFS_CMD_CDM_SET_TELLER_INFO . 63
6.10 WFS_CMD_CDM_SET_CASH_UNIT_INFO . 64
6.11 WFS_CMD_CDM_START_EXCHANGE . 66
6.12 WFS_CMD_CDM_END_EXCHANGE. 68
6.13 WFS_CMD_CDM_OPEN_SAFE_DOOR . 70
6.14 WFS_CMD_CDM_CALIBRATE_CASH_UNIT . 71
6.15 WFS_CMD_CDM_SET_MIX_TABLE . 73
SIST CWA 16926-64:2023
6.16 WFS_CMD_CDM_RESET . 74
6.17 WFS_CMD_CDM_TEST_CASH_UNITS . 76
6.18 WFS_CMD_CDM_SET_GUIDANCE_LIGHT . 78
6.19 WFS_CMD_CDM_POWER_SAVE_CONTROL . 80
6.20 WFS_CMD_CDM_PREPARE_DISPENSE . 81
6.21 WFS_CMD_CDM_SET_BLACKLIST . 82
6.22 WFS_CMD_CDM_SYNCHRONIZE_COMMAND . 83
6.23 WFS_CMD_CDM_SET_CLASSIFICATION_LIST . 84
7. Events . 85
7.1 WFS_SRVE_CDM_SAFEDOOROPEN . 85
7.2 WFS_SRVE_CDM_SAFEDOORCLOSED. 86
7.3 WFS_USRE_CDM_CASHUNITTHRESHOLD . 87
7.4 WFS_SRVE_CDM_CASHUNITINFOCHANGED . 88
7.5 WFS_SRVE_CDM_TELLERINFOCHANGED . 89
7.6 WFS_EXEE_CDM_DELAYEDDISPENSE . 90
7.7 WFS_EXEE_CDM_STARTDISPENSE . 91
7.8 WFS_EXEE_CDM_CASHUNITERROR . 92
7.9 WFS_SRVE_CDM_ITEMSTAKEN . 93
7.10 WFS_SRVE_CDM_COUNTS_CHANGED. 94
7.11 WFS_EXEE_CDM_PARTIALDISPENSE . 95
7.12 WFS_EXEE_CDM_SUBDISPENSEOK . 96
7.13 WFS_EXEE_CDM_INCOMPLETEDISPENSE . 97
7.14 WFS_EXEE_CDM_NOTEERROR . 98
7.15 WFS_SRVE_CDM_ITEMSPRESENTED . 99
7.16 WFS_SRVE_CDM_MEDIADETECTED . 100
7.17 WFS_EXEE_CDM_INPUT_P6 . 101
7.18 WFS_SRVE_CDM_DEVICEPOSITION . 102
7.19 WFS_SRVE_CDM_POWER_SAVE_CHANGE . 103
7.20 WFS_EXEE_CDM_INFO_AVAILABLE . 104
7.21 WFS_EXEE_CDM_INCOMPLETERETRACT . 105
7.22 WFS_SRVE_CDM_SHUTTERSTATUSCHANGED . 106
7.23 WFS_SRVE_CDM_ITEMSINSERTED . 107
8. Sub-Dispensing Command Flow . 108
9. Rules for Cash Unit Exchange . 111
10. Events Associated with Cash Unit Status Changes . 112
10.1 One Physical Cash Unit Goes LOW . 112
10.2 Last Physical Cash Unit Goes LOW . 113
10.3 One Physical Cash Unit Goes INOP . 114
10.4 Last Physical Cash Unit Goes EMPTY . 115
SIST CWA 16926-64:2023
11. Multiple Dispense Command Flow . 116
12. Appendix E – Cash Dispenser E2E Authentication . 118
12.1 Secure Dispense Data Parameter Example Data . 118
12.2 Secure Dispense Command Flow: - Dispense and Present . 120
12.3 Secure Dispense Command Flow – Dispense Only with no Present . 122
12.4 Secure Dispense Command Flow: - Dispense Completes With Error Followed by an
Additional Dispense and Present . 123
12.5 Secure Dispense Command Flow: - User does not remove bills. Dispense, Present and
Retract . 125
12.6 Secure Dispense Command Flow: - Authentication Process Timeout . 127
13. C - Header file . 128
SIST CWA 16926-64:2023
European Foreword
This CEN Workshop Agreement has been developed in accordance with the CEN-CENELEC Guide 29
“CEN/CENELEC Workshop Agreements – The way to rapid consensus” and with the relevant provisions of
CEN/CENELEC Internal Regulations – Part 2. It was approved by a Workshop of representatives of interested
parties on 2022-11-08, the constitution of which was supported by CEN following several public calls for
participation, the first of which was made on 1998-06-24. However, this CEN Workshop Agreement does not
necessarily include all relevant stakeholders.
The final text of this CEN Workshop Agreement was provided to CEN for publication on 2022-11-18.
The following organizations and individuals developed and approved this CEN Workshop Agreement:
• AURIGA SPA
• CIMA SPA
• DIEBOLD NIXDORF SYSTEMS GMBH
• FIS BANKING SOLUTIONS UK LTD (OTS)
• FUJITSU TECHNOLOGY SOLUTIONS
• GLORY LTD
• GRG BANKING EQUIPMENT HK CO LTD
• HITACHI CHANNEL SOLUTIONS CORP
• HYOSUNG TNS INC
• JIANGSU GUOGUANG ELECTRONIC INFORMATION TECHNOLOGY
• KAL
• KEBA HANDOVER AUTOMATION GMBH
• NCR FSG
• NEXUS SOFTWARE
• OBERTHUR CASH PROTECTION
• OKI ELECTRIC INDUSTRY SHENZHEN
• SALZBURGER BANKEN SOFTWARE
• SECURE INNOVATION
• SIGMA SPA
It is possible that some elements of this CEN/CWA may be subject to patent rights. The CEN-CENELEC policy on
patent rights is set out in CEN-CENELEC Guide 8 “Guidelines for Implementation of the Common IPR Policy on
Patents (and other statutory intellectual property rights based on inventions)”. CEN shall not be held responsible for
identifying any or all such patent rights.
The Workshop participants have made every effort to ensure the reliability and accuracy of the technical and non-
technical content of CWA 16926-5, but this does not guarantee, either explicitly or implicitly, its correctness. Users
of CWA 16926-5 should be aware that neither the Workshop participants, nor CEN can be held liable for damages
SIST CWA 16926-64:2023
or losses of any kind whatsoever which may arise from its application. Users of CWA 16926-5 do so on their own
responsibility and at their own risk.
The CWA is published as a multi-part document, consisting of:
Part 1: Application Programming Interface (API) - Service Provider Interface (SPI) - Programmer's Reference
Part 2: Service Classes Definition - Programmer's Reference
Part 3: Printer and Scanning Device Class Interface - Programmer's Reference
Part 4: Identification Card Device Class Interface - Programmer's Reference
Part 5: Cash Dispenser Device Class Interface - Programmer's Reference
Part 6: PIN Keypad Device Class Interface - Programmer's Reference
Part 7: Check Reader/Scanner Device Class Interface - Programmer's Reference
Part 8: Depository Device Class Interface - Programmer's Reference
Part 9: Text Terminal Unit Device Class Interface - Programmer's Reference
Part 10: Sensors and Indicators Unit Device Class Interface - Programmer's Reference
Part 11: Vendor Dependent Mode Device Class Interface - Programmer's Reference
Part 12: Camera Device Class Interface - Programmer's Reference
Part 13: Alarm Device Class Interface - Programmer's Reference
Part 14: Card Embossing Unit Device Class Interface - Programmer's Reference
Part 15: Cash-In Module Device Class Interface - Programmer's Reference
Part 16: Card Dispenser Device Class Interface - Programmer's Reference
Part 17: Barcode Reader Device Class Interface - Programmer's Reference
Part 18: Item Processing Module Device Class Interface - Programmer's Reference
Part 19: Biometrics Device Class Interface - Programmer's Reference
Parts 20 - 28: Reserved for future use.
Parts 29 through 47 constitute an optional addendum to this CWA. They define the integration between the SNMP
standard and the set of status and statistical information exported by the Service Providers.
Part 29: XFS MIB Architecture and SNMP Extensions - Programmer’s Reference
Part 30: XFS MIB Device Specific Definitions - Printer Device Class
Part 31: XFS MIB Device Specific Definitions - Identification Card Device Class
Part 32: XFS MIB Device Specific Definitions - Cash Dispenser Device Class
Part 33: XFS MIB Device Specific Definitions - PIN Keypad Device Class
Part 34: XFS MIB Device Specific Definitions - Check Reader/Scanner Device Class
Part 35: XFS MIB Device Specific Definitions - Depository Device Class
Part 36: XFS MIB Device Specific Definitions - Text Terminal Unit Device Class
Part 37: XFS MIB Device Specific Definitions - Sensors and Indicators Unit Device Class
Part 38: XFS MIB Device Specific Definitions - Camera Device Class
Part 39: XFS MIB Device Specific Definitions - Alarm Device Class
Part 40: XFS MIB Device Specific Definitions - Card Embossing Unit Class
Part 41: XFS MIB Device Specific Definitions - Cash-In Module Device Class
Part 42: Reserved for future use.
Part 43: XFS MIB Device Specific Definitions - Vendor Dependent Mode Device Class
Part 44: XFS MIB Application Management
Part 45: XFS MIB Device Specific Definitions - Card Dispenser Device Class
SIST CWA 16926-64:2023
Part 46: XFS MIB Device Specific Definitions - Barcode Reader Device Class
Part 47: XFS MIB Device Specific Definitions - Item Processing Module Device Class
Part 48: XFS MIB Device Specific Definitions - Biometrics Device Class
Parts 49 - 60 are reserved for future use.
Part 61: Application Programming Interface (API) - Migration from Version 3.40 (CWA 16296:2020) to Version
3.50 (this CWA) - Service Provider Interface (SPI) - Programmer's Reference
Part 62: Printer and Scanning Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version
3.50 (this CWA) - Programmer's Reference
Part 63: Identification Card Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version
3.50 (this CWA) - Programmer's Reference
Part 64: Cash Dispenser Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 65: PIN Keypad Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 66: Check Reader/Scanner Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 67: Depository Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50 (this
CWA) - Programmer's Reference
Part 68: Text Terminal Unit Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version
3.50 (this CWA) - Programmer's Reference
Part 69: Sensors and Indicators Unit Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 70: Vendor Dependent Mode Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 71: Camera Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50 (this
CWA) - Programmer's Reference
Part 72: Alarm Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50 (this
CWA) - Programmer's Reference
Part 73: Card Embossing Unit Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 74: Cash-In Module Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 75: Card Dispenser Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 76: Barcode Reader Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 77: Item Processing Module Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 78: Biometric Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50 (this
CWA) - Programmer's Reference
In addition to these Programmer's Reference specifications, the reader of this CWA is also referred to a
complementary document, called Release Notes. The Release Notes contain clarifications and explanations on the
CWA specifications, which are not requiring functional changes. The current version of the Release Notes is
available online from: https://www.cencenelec.eu/areas-of-work/cen-sectors/digital-society-cen/cwa-download-
area/.
The information in this document represents the Workshop's current views on the issues discussed as of the date of
publication. It is provided for informational purposes only and is subject to change without notice. CEN makes no
warranty, express or implied, with respect to this document.
SIST CWA 16926-64:2023
Revision History:
3.00 October 18, 2000 Initial Release.
3.10 November 29, 2007 For a description of changes from version 3.00 to version
3.10 see the CDM 3.10 Migration document.
3.20 March 2, 2011 For a description of changes from version 3.10 to version
3.20 see the CDM 3.20 Migration document.
3.30 March 19, 2015 For a description of changes from version 3.20 to version
3.30 see the CDM 3.30 Migration document.
3.40 December 06, 2019 For a description of changes from version 3.30 to version
3.40 see the CDM 3.40 Migration document.
3.50 November 18, 2022 For a description of changes from version 3.40 to version
3.50 see the CDM 3.50 Migration document.
SIST CWA 16926-64:2023
1. Introduction
1.1 Background to Release 3.50
The CEN/XFS Workshop aims to promote a clear and unambiguous specification defining a multi-vendor software
interface to financial peripheral devices. The XFS (eXtensions for Financial Services) specifications are developed
within the CEN (European Committee for Standardization/Information Society Standardization System) Workshop
environment. CEN Workshops aim to arrive at a European consensus on an issue that can be published as a CEN
Workshop Agreement (CWA).
The CEN/XFS Workshop encourages the participation of both banks and vendors in the deliberations required to
create an industry standard. The CEN/XFS Workshop achieves its goals by focused sub-groups working
electronically and meeting quarterly.
Release 3.50 of the XFS specification is based on a C API and is delivered with the continued promise for the
protection of technical investment for existing applications. This release of the specification extends the
functionality and capabilities of the existing devices covered by the specification:
• Addition of E2E security
• PIN Password Entry
1.2 XFS Service-Specific Programming
The service classes are defined by their service-specific commands and the associated data structures, error codes,
messages, etc. These commands are used to request functions that are specific to one or more classes of Service
Providers, but not all of them, and therefore are not included in the common API for basic or administration
functions.
When a service-specific command is common among two or more classes of Service Providers, the syntax of the
command is as similar as possible across all services, since a major objective of XFS is to standardize function
codes and structures for the broadest variety of services. For example, using the WFSExecute function, the
commands to read data from various services are as similar as possible to each other in their syntax and data
structures.
In general, the specific command set for a service class is defined as a superset of the specific capabilities likely to
be provided by the developers of the services of that class; thus any particular device will normally support only a
subset of the defined command set.
There are three cases in which a Service Provider may receive a service-specific command that it does not support:
The requested capability is defined for the class of Service Providers by the XFS specification, the particular vendor
implementation of that service does not support it, and the unsupported capability is not considered to be
fundamental to the service. In this case, the Service Provider returns a successful completion, but does no operation.
An example would be a request from an application to turn on a control indicator on a passbook printer; the Service
Provider recognizes the command, but since the passbook printer it is managing does not include that indicator, the
Service Provider does no operation and returns a successful completion to the application.
The requested capability is defined for the class of Service Providers by the XFS specification, the particular vendor
implementation of that service does not support it, and the unsupported capability is considered to be fundamental
to the service. In this case, a WFS_ERR_UNSUPP_COMMAND error for Execute commands or
WFS_ERR_UNSUPP_CATEGORY error for Info commands is returned to the calling application. An example
would be a request from an application to a cash dispenser to retract items where the dispenser hardware does not
have that capability; the Service Provider recognizes the command but, since the cash dispenser it is managing is
unable to fulfil the request, returns this error.
The requested capability is not defined for the class of Service Providers by the XFS specification. In this case, a
WFS_ERR_INVALID_COMMAND for Execute commands or WFS_ERR_INVALID_CATEGORY error for Info
commands error is returned to the calling application.
This design allows implementation of applications that can be used with a range of services that provide differing
subsets of the functionalities that are defined for their service class. Applications may use the WFSGetInfo and
WFSAsyncGetInfo commands to inquire about the capabilities of the service they are about to use, and modify
their behavior accordingly, or they may use functions and then deal with error returns to make decisions as to how
to use the service.
SIST CWA 16926-64:2023
2. Cash Dispensers
This specification describes the functionality of an XFS compliant Cash Dispenser Module (CDM) Service
Provider. It defines the service-specific commands that can be issued to the Service Provider using the
WFSGetInfo, WFSAsyncGetInfo, WFSExecute and WFSAsyncExecute functions.
Persistent values are maintained through power failures, open sessions, close session and system resets.
This specification covers the dispensing of items. An “item” is defined as any media that can be dispensed and
includes coupons, documents, bills and coins. However, if coins and bills are both to be dispensed separate Service
Providers must be implemented for each.
All currency parameters in this specification are expressed as a quantity of minimum dispense units, as defined in
the description of the WFS_INF_CDM_CURRENCY_EXP command.
There are two types of CDM: Self-Service CDM and Teller CDM. A Self-Service CDM operates in an automated
environment, while a Teller CDM has an operator present. The functionality provided by the following commands
is only applicable to a Teller CDM:
WFS_CMD_CDM_SET_TELLER_INFO
WFS_INF_CDM_TELLER_INFO
It is possible for the CDM to be part of a compound device with the Cash-In Module (CIM). This CIM\CDM
combination is referred to throughout this specification as a “Cash Recycler”. For details of the CIM interface see
[Ref. 3].
If the device is a Cash Recycler then, if cash unit exchanges are required on both interfaces, the exchanges cannot
be performed concurrently. An exchange on one interface must be complete (the
WFS_CMD_CDM_END_EXCHANGE must have completed) before an exchange can start on the other interface.
The WFS_ERR_CDM_EXCHANGEACTIVE error code will be returned if the correct sequence is not adhered to.
The CIM interface can be used for all exchange operations on recycle devices, and the CIM interface should be
used if the device has recycle units of multiple currencies and/or denominations (including multiple note identifiers
associated with the same denomination).
The event WFS_SRVE_CDM_COUNTS_CHANGED will be posted if an operation on the CIM interface affects
the cash unit counts which are available through the CDM interface.
The following commands on the CIM interface may affect the CDM counts:
WFS_CMD_CIM_CASH_IN
WFS_CMD_CIM_CASH_IN_END
WFS_CMD_CIM_CASH_IN_ROLLBACK
WFS_CMD_CIM_RETRACT
WFS_CMD_CIM_SET_CASH_IN_UNIT_INFO
WFS_CMD_CIM_END_EXCHANGE
WFS_CMD_CIM_RESET
WFS_CMD_CIM_REPLENISH
WFS_CMD_CIM_CASH_UNIT_COUNT
SIST CWA 16926-64:2023
3. References
1. XFS Application Programming Interface (API)/Service Provider Interface ( SPI), Programmer’s Reference,
Revision 3.4050
2. ISO 4217 at http://www.iso.orghttp://www.iso.org
3. XFS Cash-In Module Device Class Interface, Programmer’s Reference, Revision 3.4050
SIST CWA 16926-64:2023
4. Note Classification
Notes are classified by the XFS CDM specification according to the following definitions:
1. Level 1 – Note is not recognized.
2. Level 2 – Recognized counterfeit note.
3. Level 3 – Suspected counterfeit note.
4. Level 4 – Recognized note that is identified as genuine. This includes notes which are fit or unfit for
recycling.
This definition allows support for legislative note handling standards that may exist in various countries and
economic regions. Local requirements or device capability may dictate that notes are not classified as level 2 and
level 3 and therefore counterfeit or suspect notes would be classified as level 1; the P6 string reported by
WFS_INF_CIM_CAPABILITIES lpszExtra reports whether notes are classified into all 4 levels.
The above classification levels can be used to support note handling functionality which includes:
1. The ability to remove counterfeit notes from circulation.
2. Reporting of unrecognized, recognized counterfeit and suspected counterfeit notes.
3. Creating and reporting of note signatures in order to allow back-tracing of notes.
A note’s classification can be changed based on the note’s serial number, currency and value by specifying a
blacklist or classification list. A blacklist reclassifies a matching note as level 2, whereas a classification list can be
used to re-classify a matching note to a lower level, including classifying a genuine note as unfit for dispensing.
Once reclassified, the note will be automatically handled according to the local country specific note handling
standard or legislation. Any reclassification will result in the normal events and behavior, for example a
WFS_EXEE_CDM_INFO_AVAILABLE event will reflect the note’s reclassification. Reclassification can be used
to make dynamic changes to note handling procedures without a software upgrade, enabling functionality such as
taking older notes out of circulation or handling of counterfeit notes on a local basis.
Reclassification cannot be used to change a note’s classification to a higher level, for example, a note recognized as
counterfeit by the device cannot be reclassified as genuine. In addition, it is not possible to re-classify a level 2 note
as level 1. No particular use case has been identified for reclassifying Level 3 and 4 notes as level 1, but there is no
reason to restrict this reclassification.
Blacklists can be specified using WFS_CMD_CDM_SET_BLACKLIST and retrieved using
WFS_INF_CDM_GET_BLACKLIST. Classification lists can be specified using
WFS_CMD_CDM_SET_CLASSIFICATION_LIST and retrieved using
WFS_INF_CDM_GET_CLASSIFICATION_LIST. A classification list is a superset of the blacklist; any items
specified as level 2 in the classification list are considered part of the blacklist. However, it is not recommended
that both sets of commands are used by a single application, as it may lead to overlap and confusion.
The blacklist or classification list functionality can use a mask to specify serial numbers. The mask is defined as
follows: A '?' character (0x003F) is the wildcard used to match a single Unicode character, and a '*' character
(0x002A) is the wildcard used to match one or more Unicode characters.
For example, “S8H9??16?4” would represent a match for the serial numbers “S8H9231654” and “S8H9761684”. A
mask of “HD90*2” would be used in order to match serial numbers that begin with “HD90” and end with “2”, for
example “HD9028882”, “HD9083276112”. Note that the mask can only use one asterisk, and if a real character is
required then it must be preceded by a backslash, for example: '\\' for a backslash, '\*' for an asterisk or '\?' for a
question mark.
Note that this flexibility means that it is possible to overlap definitions, for example “HD90*” and “HD902*”
would both match on the serial number HD9028882”.
SIST CWA 16926-64:2023
5. Info Commands
5.1 WFS_INF_CDM_STATUS
Description This command is used to obtain the status of the CDM. It may also return vendor-specific status
information.
Input Param None.
Output Param LPWFSCDMSTATUS lpStatus;
typedef struct _wfs_cdm_status
{
WORD fwDevice;
WORD fwSafeDoor;
WORD fwDispenser;
WORD fwIntermediateStacker;
LPWFSCDMOUTPOS *lppPositions;
LPSTR lpszExtra;
DWORD dwGuidLights[WFS_CDM_GUIDLIGHTS_SIZE];
WORD wDevicePosition;
USHORT usPowerSaveRecoveryTime;
WORD wAntiFraudModule;
} WFSCDMSTATUS, *LPWFSCDMSTATUS;
fwDevice
Supplies the state of the CDM. However, an fwDevice status of WFS_CDM_DEVONLINE does
not necessarily imply that dispensing can take place: the value of the fwDispenser field must be
taken into account and - for some vendors - the state of the safe door (fwSafeDoor) may also be
relevant. The state of the CDM will have one of the following values:
Value Meaning
WFS_CDM_DEVONLINE The device is online. This is returned when
the dispenser is present and operational.
WFS_CDM_DEVOFFLINE The device is offline (e.g. the operator has
taken the device offline by turning a switch).
WFS_CDM_DEVPOWEROFF The device is powered off or physically not
connected.
WFS_CDM_DEVNODEVICE The device is not intended to be there, e.g.
this type of self service machine does not
contain such a device or it is internally not
configured.
WFS_CDM_DEVHWERROR The device is inoperable due to a hardware
error.
WFS_CDM_DEVUSERERROR The device is present but a person is
preventing proper device operation.
WFS_CDM_DEVBUSY The device is busy and unable to process an
execute command at this time.
WFS_CDM_DEVFRAUDATTEMPT The device is present but is inoperable
because it has detected a fraud attempt.
WFS_CDM_DEVPOTENTIALFRAUD The device has detected a potential fraud
attempt and is capable of remaining in
service. In this case the application should
make the decision as to whether to take the
device offline.
fwSafeDoor
Supplies the state of the safe door as one of the following values:
Value Meaning
WFS_CDM_DOORNOTSUPPORTED Physical device has no safe door or safe door
state reporting is not supported.
WFS_CDM_DOOROPEN Safe door is open.
WFS_CDM_DOORCLOSED Safe door is closed.
SIST CWA 16926-64:2023
WFS_CDM_DOORUNKNOWN Due to a hardware error or other condition,
the state of the safe door cannot be
determined.
fwDispenser
Supplies the state of the dispenser’s logical cash units as one of the following values:
Value Meaning
WFS_CDM_DISPOK All cash units present are in a good state.
WFS_CDM_DISPCUSTATE One or more of the cash units is in a low,
empty, inoperative or manipulated condition.
Items can still be dispensed from at least one
of the cash units.
WFS_CDM_DISPCUSTOP Due to a cash unit failure dispensing is
impossible. No items can be dispensed
because all of the cash units are in an empty,
inoperative or manipulated condition. This
state may also occur when a reject/retract
cash unit is full or no reject/retract cash unit
is present, or when an application lock is set
on every cash unit which can be locked.
WFS_CDM_DISPCUUNKNOWN Due to a hardware error or other condition,
the state of the cash units cannot be
determined.
fwIntermediateStacker
Supplies the state of the intermediate stacker. These bills are typically present on the intermediate
stacker as a result of a retract operation or because a dispense has been performed without a
subsequent present. Possible values for this field are:
Value Meaning
WFS_CDM_ISEMPTY The intermediate stacker is empty.
WFS_CDM_ISNOTEMPTY The intermediate stacker is not empty. The
items have not been in customer access.
WFS_CDM_ISNOTEMPTYCUST The intermediate stacker is not empty. The
items have been in customer access. If the
device is a recycler then the items on the
intermediate stacker may be there as a result
of a previous cash-in operation.
WFS_CDM_ISNOTEMPTYUNK The intermediate stacker is not empty. It is
not known if the items have been in
customer access.
WFS_CDM_ISUNKNOWN Due to a hardware error or other condition,
the state of the intermediate stacker cannot
be determined.
WFS_CDM_ISNOTSUPPORTED The physical device has no intermediate
stacker.
lppPositions
Pointer to a NULL-terminated array of pointers to WFSCDMOUTPOS structures. There is one
structure for each position to which items can be dispensed or presented:
typedef struct _wfs_cdm_position
{
WORD fwPosition;
WORD fwShutter;
WORD fwPositionStatus;
WORD fwTransport;
WORD fwTransportStatus;
WORD fwJammedShutterPosition;
} WFSCDMOUTPOS, *LPWFSCDMOUTPOS;
fwPosition
Supplies the output position as one of the following values:
Value Meaning
WFS_CDM_POSLEFT Left output position.
SIST CWA 16926-64:2023
WFS_CDM_POSRIGHT Right output position.
WFS_CDM_POSCENTER Center output position.
WFS_CDM_POSTOP Top output position.
WFS_CDM_POSBOTTOM Bottom output position.
WFS_CDM_POSFRONT Front output position.
WFS_CDM_POSREAR Rear output position.
fwShutter
Supplies the state of the shutter as one of the following values:
Value Meaning
WFS_CDM_SHTCLOSED The shutter is operational and is closed.
WFS_CDM_SHTOPEN The shutter is operational and is open.
WFS_CDM_SHTJAMMED The shutter is jammed and is not
operational. The field
fwJammedShutterPosition provides the
positional state of the shutter.
WFS_CDM_SHTUNKNOWN Due to a hardware error or other
condition, the state of the shutter cannot
be determined.
WFS_CDM_SHTNOTSUPPORTED The physical device has no shutter or
shutter state reporting is not supported.
fwPositionStatus
Returns information regarding items which may be at the output position. If the device is a
recycler it is possible that the output position will not be empty due to a previous cash-in
operation. The possible values of this field are:
Value Meaning
WFS_CDM_PSEMPTY The output position is empty.
WFS_CDM_PSNOTEMPTY The output position is not empty.
WFS_CDM_PSUNKNOWN Due to a hardware error or other
condition, the state of the output position
cannot be determined.
WFS_CDM_PSNOTSUPPORTED The device is not capable of reporting
whether or not items are at the output
position.
fwTransport
Supplies the state of the transport mechanism as one of the following values. The transport is
defined as any area leading to or from the position:
Value Meaning
WFS_CDM_TPOK The transport is in a good state.
WFS_CDM_TPINOP The transport is inoperative due to a
hardware failure or media jam.
WFS_CDM_TPUNKNOWN Due to a hardware error or other
condition the state of the transport cannot
be determined.
WFS_CDM_TPNOTSUPPORTED The physical device has no transport or
transport state reporting is not supported.
fwTransportStatus
Returns information regarding items which may be on the transport. If the device is a recycler
device it is possible that the transport will not be empty due to a previous cash-in operation.
The possible values of this field are:
Value Meaning
WFS_CDM_TPSTATEMPTY The transport is empty.
WFS_CDM_TPSTATNOTEMPTY The transport is not empty.
WFS_CDM_TPSTATNOTEMPTYCUST Items which a customer has had access to
are on the transport.
WFS_CDM_TPSTATNOTEMPTY_UNK Due to a hardware error or other
condition it is not known whether there
are items on the transport.
SIST CWA 16926-64:2023
WFS_CDM_TPSTATNOTSUPPORTED The device is not capable of reporting
whether items are on the transport.
fwJammedShutterPosition
Returns information regarding the position of the jammed shutter. The possible values of this
field are:
Value Meaning
WFS_CDM_SHUTTERPOS_NOTSUPPORTED The physical device has no shutter or
the reporting of the position of a
jammed shutter is not supported.
WFS_CDM_SHUTTERPOS_NOTJAMMED The shutter is not jammed.
WFS_CDM_SHUTTERPOS_OPEN The shutter is jammed, but fully open.
WFS_CDM_SHUTTERPOS_PARTIALLY_OPEN The shutter is jammed, but partially
open.
WFS_CDM_SHUTTERPOS_CLOSED The shutter is jammed, but fully
closed.
WFS_CDM_SHUTTERPOS_UNKNOWN The position of the shutter is
unknown.
lpszExtra
Pointer to a list of vendor-specific, or any other extended, information. The information is
returned as a series of “key=value” strings so that it is easily extensible by Service Providers.
Each string is null-terminated, with the final string terminating with two null characters. An
empty list may be indicated by either a NULL pointer or a pointer to two consecutive null
characters.
dwGuidLights [.]
Specifies the state of the guidance light indicators. The elements of this array can be accessed by
using the predefined index values specified for the dwGuidLights [ ] field in the capabilities.
Vendor specific guidance lights are defined starting from the end of the array. The maximum
guidance light index is WFS_CDM_GUIDLIGHTS_MAX.
Specifies the state of the guidance light indicator as
WFS_CDM_GUIDANCE_NOT_AVAILABLE, WFS_CDM_GUIDANCE_OFF or a
combination of the following flags consisting of one type B, optionally one type C and optionally
one type D.
Value Meaning Type
WFS_CDM_GUIDANCE_NOT_AVAILABLE The status is not available. A
WFS_CDM_GUIDANCE_OFF The light is turned o
...
SLOVENSKI STANDARD
01-april-2023
Specifikacija vmesnika razširitev za finančne storitve (XFS), izdaja 3.50 - 64. del:
Vmesnik razreda modula blagajniškega avtomata - Referenca za programerje -
Prehod z različice 3.40 (CWA 16926:2020) na različico 3.50 (ta CWA)
Extensions for Financial Services (XFS) interface specification Release 3.50 - Part 64:
Cash Dispenser Module Class Interface - Programmer's Reference - Migration from
Version 3.40 (CWA 16926:2020) to Version 3.50 (this CWA)
Ta slovenski standard je istoveten z: CWA 16926-64:2023
ICS:
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
35.240.15 Identifikacijske kartice. Čipne Identification cards. Chip
kartice. Biometrija cards. Biometrics
35.240.40 Uporabniške rešitve IT v IT applications in banking
bančništvu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
CEN
CWA 16926-64
WORKSHOP
January 2023
AGREEMENT
ICS 35.200; 35.240.15; 35.240.40
English version
Extensions for Financial Services (XFS) interface
specification Release 3.50 - Part 64: Cash Dispenser
Module Class Interface - Programmer's Reference -
Migration from Version 3.40 (CWA 16926:2020) to
Version 3.50 (this CWA)
This CEN Workshop Agreement has been drafted and approved by a Workshop of representatives of interested parties, the
constitution of which is indicated in the foreword of this Workshop Agreement.
The formal process followed by the Workshop in the development of this Workshop Agreement has been endorsed by the
National Members of CEN but neither the National Members of CEN nor the CEN-CENELEC Management Centre can be held
accountable for the technical content of this CEN Workshop Agreement or possible conflicts with standards or legislation.
This CEN Workshop Agreement can in no way be held as being an official standard developed by CEN and its Members.
This CEN Workshop Agreement is publicly available as a reference document from the CEN Members National Standard Bodies.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2023 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.
Ref. No.:CWA 16926-64:2023 E
Table of Contents
European Foreword . 5
1. Introduction . 9
1.1 Background to Release 3.50 . 9
1.2 XFS Service-Specific Programming . 9
2. Cash Dispensers . 10
3. References . 11
4. Note Classification . 12
5. Info Commands . 13
5.1 WFS_INF_CDM_STATUS . 13
5.2 WFS_INF_CDM_CAPABILITIES . 18
5.3 WFS_INF_CDM_CASH_UNIT_INFO . 23
5.4 WFS_INF_CDM_TELLER_INFO . 30
5.5 WFS_INF_CDM_CURRENCY_EXP . 32
5.6 WFS_INF_CDM_MIX_TYPES . 33
5.7 WFS_INF_CDM_MIX_TABLE . 34
5.8 WFS_INF_CDM_PRESENT_STATUS. 35
5.9 WFS_INF_CDM_GET_ITEM_INFO . 37
5.10 WFS_INF_CDM_GET_BLACKLIST . 39
5.11 WFS_INF_CDM_GET_ALL_ITEMS_INFO . 40
5.12 WFS_INF_CDM_GET_CLASSIFICATION_LIST . 43
6. Execute Commands . 45
6.1 WFS_CMD_CDM_DENOMINATE . 45
6.2 WFS_CMD_CDM_DISPENSE . 48
6.3 WFS_CMD_CDM_COUNT . 52
6.4 WFS_CMD_CDM_PRESENT . 55
6.5 WFS_CMD_CDM_REJECT . 57
6.6 WFS_CMD_CDM_RETRACT . 58
6.7 WFS_CMD_CDM_OPEN_SHUTTER . 61
6.8 WFS_CMD_CDM_CLOSE_SHUTTER . 62
6.9 WFS_CMD_CDM_SET_TELLER_INFO . 63
6.10 WFS_CMD_CDM_SET_CASH_UNIT_INFO . 64
6.11 WFS_CMD_CDM_START_EXCHANGE . 66
6.12 WFS_CMD_CDM_END_EXCHANGE. 68
6.13 WFS_CMD_CDM_OPEN_SAFE_DOOR . 70
6.14 WFS_CMD_CDM_CALIBRATE_CASH_UNIT . 71
6.15 WFS_CMD_CDM_SET_MIX_TABLE . 73
6.16 WFS_CMD_CDM_RESET . 74
6.17 WFS_CMD_CDM_TEST_CASH_UNITS . 76
6.18 WFS_CMD_CDM_SET_GUIDANCE_LIGHT . 78
6.19 WFS_CMD_CDM_POWER_SAVE_CONTROL . 80
6.20 WFS_CMD_CDM_PREPARE_DISPENSE . 81
6.21 WFS_CMD_CDM_SET_BLACKLIST . 82
6.22 WFS_CMD_CDM_SYNCHRONIZE_COMMAND . 83
6.23 WFS_CMD_CDM_SET_CLASSIFICATION_LIST . 84
7. Events . 85
7.1 WFS_SRVE_CDM_SAFEDOOROPEN . 85
7.2 WFS_SRVE_CDM_SAFEDOORCLOSED. 86
7.3 WFS_USRE_CDM_CASHUNITTHRESHOLD . 87
7.4 WFS_SRVE_CDM_CASHUNITINFOCHANGED . 88
7.5 WFS_SRVE_CDM_TELLERINFOCHANGED . 89
7.6 WFS_EXEE_CDM_DELAYEDDISPENSE . 90
7.7 WFS_EXEE_CDM_STARTDISPENSE . 91
7.8 WFS_EXEE_CDM_CASHUNITERROR . 92
7.9 WFS_SRVE_CDM_ITEMSTAKEN . 93
7.10 WFS_SRVE_CDM_COUNTS_CHANGED. 94
7.11 WFS_EXEE_CDM_PARTIALDISPENSE . 95
7.12 WFS_EXEE_CDM_SUBDISPENSEOK . 96
7.13 WFS_EXEE_CDM_INCOMPLETEDISPENSE . 97
7.14 WFS_EXEE_CDM_NOTEERROR . 98
7.15 WFS_SRVE_CDM_ITEMSPRESENTED . 99
7.16 WFS_SRVE_CDM_MEDIADETECTED . 100
7.17 WFS_EXEE_CDM_INPUT_P6 . 101
7.18 WFS_SRVE_CDM_DEVICEPOSITION . 102
7.19 WFS_SRVE_CDM_POWER_SAVE_CHANGE . 103
7.20 WFS_EXEE_CDM_INFO_AVAILABLE . 104
7.21 WFS_EXEE_CDM_INCOMPLETERETRACT . 105
7.22 WFS_SRVE_CDM_SHUTTERSTATUSCHANGED . 106
7.23 WFS_SRVE_CDM_ITEMSINSERTED . 107
8. Sub-Dispensing Command Flow . 108
9. Rules for Cash Unit Exchange . 111
10. Events Associated with Cash Unit Status Changes . 112
10.1 One Physical Cash Unit Goes LOW . 112
10.2 Last Physical Cash Unit Goes LOW . 113
10.3 One Physical Cash Unit Goes INOP . 114
10.4 Last Physical Cash Unit Goes EMPTY . 115
11. Multiple Dispense Command Flow . 116
12. Appendix E – Cash Dispenser E2E Authentication . 118
12.1 Secure Dispense Data Parameter Example Data . 118
12.2 Secure Dispense Command Flow: - Dispense and Present . 120
12.3 Secure Dispense Command Flow – Dispense Only with no Present . 122
12.4 Secure Dispense Command Flow: - Dispense Completes With Error Followed by an
Additional Dispense and Present . 123
12.5 Secure Dispense Command Flow: - User does not remove bills. Dispense, Present and
Retract . 125
12.6 Secure Dispense Command Flow: - Authentication Process Timeout . 127
13. C - Header file . 128
European Foreword
This CEN Workshop Agreement has been developed in accordance with the CEN-CENELEC Guide 29
“CEN/CENELEC Workshop Agreements – The way to rapid consensus” and with the relevant provisions of
CEN/CENELEC Internal Regulations – Part 2. It was approved by a Workshop of representatives of interested
parties on 2022-11-08, the constitution of which was supported by CEN following several public calls for
participation, the first of which was made on 1998-06-24. However, this CEN Workshop Agreement does not
necessarily include all relevant stakeholders.
The final text of this CEN Workshop Agreement was provided to CEN for publication on 2022-11-18.
The following organizations and individuals developed and approved this CEN Workshop Agreement:
• AURIGA SPA
• CIMA SPA
• DIEBOLD NIXDORF SYSTEMS GMBH
• FIS BANKING SOLUTIONS UK LTD (OTS)
• FUJITSU TECHNOLOGY SOLUTIONS
• GLORY LTD
• GRG BANKING EQUIPMENT HK CO LTD
• HITACHI CHANNEL SOLUTIONS CORP
• HYOSUNG TNS INC
• JIANGSU GUOGUANG ELECTRONIC INFORMATION TECHNOLOGY
• KAL
• KEBA HANDOVER AUTOMATION GMBH
• NCR FSG
• NEXUS SOFTWARE
• OBERTHUR CASH PROTECTION
• OKI ELECTRIC INDUSTRY SHENZHEN
• SALZBURGER BANKEN SOFTWARE
• SECURE INNOVATION
• SIGMA SPA
It is possible that some elements of this CEN/CWA may be subject to patent rights. The CEN-CENELEC policy on
patent rights is set out in CEN-CENELEC Guide 8 “Guidelines for Implementation of the Common IPR Policy on
Patents (and other statutory intellectual property rights based on inventions)”. CEN shall not be held responsible for
identifying any or all such patent rights.
The Workshop participants have made every effort to ensure the reliability and accuracy of the technical and non-
technical content of CWA 16926-5, but this does not guarantee, either explicitly or implicitly, its correctness. Users
of CWA 16926-5 should be aware that neither the Workshop participants, nor CEN can be held liable for damages
or losses of any kind whatsoever which may arise from its application. Users of CWA 16926-5 do so on their own
responsibility and at their own risk.
The CWA is published as a multi-part document, consisting of:
Part 1: Application Programming Interface (API) - Service Provider Interface (SPI) - Programmer's Reference
Part 2: Service Classes Definition - Programmer's Reference
Part 3: Printer and Scanning Device Class Interface - Programmer's Reference
Part 4: Identification Card Device Class Interface - Programmer's Reference
Part 5: Cash Dispenser Device Class Interface - Programmer's Reference
Part 6: PIN Keypad Device Class Interface - Programmer's Reference
Part 7: Check Reader/Scanner Device Class Interface - Programmer's Reference
Part 8: Depository Device Class Interface - Programmer's Reference
Part 9: Text Terminal Unit Device Class Interface - Programmer's Reference
Part 10: Sensors and Indicators Unit Device Class Interface - Programmer's Reference
Part 11: Vendor Dependent Mode Device Class Interface - Programmer's Reference
Part 12: Camera Device Class Interface - Programmer's Reference
Part 13: Alarm Device Class Interface - Programmer's Reference
Part 14: Card Embossing Unit Device Class Interface - Programmer's Reference
Part 15: Cash-In Module Device Class Interface - Programmer's Reference
Part 16: Card Dispenser Device Class Interface - Programmer's Reference
Part 17: Barcode Reader Device Class Interface - Programmer's Reference
Part 18: Item Processing Module Device Class Interface - Programmer's Reference
Part 19: Biometrics Device Class Interface - Programmer's Reference
Parts 20 - 28: Reserved for future use.
Parts 29 through 47 constitute an optional addendum to this CWA. They define the integration between the SNMP
standard and the set of status and statistical information exported by the Service Providers.
Part 29: XFS MIB Architecture and SNMP Extensions - Programmer’s Reference
Part 30: XFS MIB Device Specific Definitions - Printer Device Class
Part 31: XFS MIB Device Specific Definitions - Identification Card Device Class
Part 32: XFS MIB Device Specific Definitions - Cash Dispenser Device Class
Part 33: XFS MIB Device Specific Definitions - PIN Keypad Device Class
Part 34: XFS MIB Device Specific Definitions - Check Reader/Scanner Device Class
Part 35: XFS MIB Device Specific Definitions - Depository Device Class
Part 36: XFS MIB Device Specific Definitions - Text Terminal Unit Device Class
Part 37: XFS MIB Device Specific Definitions - Sensors and Indicators Unit Device Class
Part 38: XFS MIB Device Specific Definitions - Camera Device Class
Part 39: XFS MIB Device Specific Definitions - Alarm Device Class
Part 40: XFS MIB Device Specific Definitions - Card Embossing Unit Class
Part 41: XFS MIB Device Specific Definitions - Cash-In Module Device Class
Part 42: Reserved for future use.
Part 43: XFS MIB Device Specific Definitions - Vendor Dependent Mode Device Class
Part 44: XFS MIB Application Management
Part 45: XFS MIB Device Specific Definitions - Card Dispenser Device Class
Part 46: XFS MIB Device Specific Definitions - Barcode Reader Device Class
Part 47: XFS MIB Device Specific Definitions - Item Processing Module Device Class
Part 48: XFS MIB Device Specific Definitions - Biometrics Device Class
Parts 49 - 60 are reserved for future use.
Part 61: Application Programming Interface (API) - Migration from Version 3.40 (CWA 16296:2020) to Version
3.50 (this CWA) - Service Provider Interface (SPI) - Programmer's Reference
Part 62: Printer and Scanning Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version
3.50 (this CWA) - Programmer's Reference
Part 63: Identification Card Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version
3.50 (this CWA) - Programmer's Reference
Part 64: Cash Dispenser Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 65: PIN Keypad Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 66: Check Reader/Scanner Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 67: Depository Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50 (this
CWA) - Programmer's Reference
Part 68: Text Terminal Unit Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version
3.50 (this CWA) - Programmer's Reference
Part 69: Sensors and Indicators Unit Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 70: Vendor Dependent Mode Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 71: Camera Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50 (this
CWA) - Programmer's Reference
Part 72: Alarm Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50 (this
CWA) - Programmer's Reference
Part 73: Card Embossing Unit Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 74: Cash-In Module Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 75: Card Dispenser Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 76: Barcode Reader Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50
(this CWA) - Programmer's Reference
Part 77: Item Processing Module Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to
Version 3.50 (this CWA) - Programmer's Reference
Part 78: Biometric Device Class Interface - Migration from Version 3.40 (CWA 16296:2020) to Version 3.50 (this
CWA) - Programmer's Reference
In addition to these Programmer's Reference specifications, the reader of this CWA is also referred to a
complementary document, called Release Notes. The Release Notes contain clarifications and explanations on the
CWA specifications, which are not requiring functional changes. The current version of the Release Notes is
available online from: https://www.cencenelec.eu/areas-of-work/cen-sectors/digital-society-cen/cwa-download-
area/.
The information in this document represents the Workshop's current views on the issues discussed as of the date of
publication. It is provided for informational purposes only and is subject to change without notice. CEN makes no
warranty, express or implied, with respect to this document.
Revision History:
3.00 October 18, 2000 Initial Release.
3.10 November 29, 2007 For a description of changes from version 3.00 to version
3.10 see the CDM 3.10 Migration document.
3.20 March 2, 2011 For a description of changes from version 3.10 to version
3.20 see the CDM 3.20 Migration document.
3.30 March 19, 2015 For a description of changes from version 3.20 to version
3.30 see the CDM 3.30 Migration document.
3.40 December 06, 2019 For a description of changes from version 3.30 to version
3.40 see the CDM 3.40 Migration document.
3.50 November 18, 2022 For a description of changes from version 3.40 to version
3.50 see the CDM 3.50 Migration document.
1. Introduction
1.1 Background to Release 3.50
The CEN/XFS Workshop aims to promote a clear and unambiguous specification defining a multi-vendor software
interface to financial peripheral devices. The XFS (eXtensions for Financial Services) specifications are developed
within the CEN (European Committee for Standardization/Information Society Standardization System) Workshop
environment. CEN Workshops aim to arrive at a European consensus on an issue that can be published as a CEN
Workshop Agreement (CWA).
The CEN/XFS Workshop encourages the participation of both banks and vendors in the deliberations required to
create an industry standard. The CEN/XFS Workshop achieves its goals by focused sub-groups working
electronically and meeting quarterly.
Release 3.50 of the XFS specification is based on a C API and is delivered with the continued promise for the
protection of technical investment for existing applications. This release of the specification extends the
functionality and capabilities of the existing devices covered by the specification:
• Addition of E2E security
• PIN Password Entry
1.2 XFS Service-Specific Programming
The service classes are defined by their service-specific commands and the associated data structures, error codes,
messages, etc. These commands are used to request functions that are specific to one or more classes of Service
Providers, but not all of them, and therefore are not included in the common API for basic or administration
functions.
When a service-specific command is common among two or more classes of Service Providers, the syntax of the
command is as similar as possible across all services, since a major objective of XFS is to standardize function
codes and structures for the broadest variety of services. For example, using the WFSExecute function, the
commands to read data from various services are as similar as possible to each other in their syntax and data
structures.
In general, the specific command set for a service class is defined as a superset of the specific capabilities likely to
be provided by the developers of the services of that class; thus any particular device will normally support only a
subset of the defined command set.
There are three cases in which a Service Provider may receive a service-specific command that it does not support:
The requested capability is defined for the class of Service Providers by the XFS specification, the particular vendor
implementation of that service does not support it, and the unsupported capability is not considered to be
fundamental to the service. In this case, the Service Provider returns a successful completion, but does no operation.
An example would be a request from an application to turn on a control indicator on a passbook printer; the Service
Provider recognizes the command, but since the passbook printer it is managing does not include that indicator, the
Service Provider does no operation and returns a successful completion to the application.
The requested capability is defined for the class of Service Providers by the XFS specification, the particular vendor
implementation of that service does not support it, and the unsupported capability is considered to be fundamental
to the service. In this case, a WFS_ERR_UNSUPP_COMMAND error for Execute commands or
WFS_ERR_UNSUPP_CATEGORY error for Info commands is returned to the calling application. An example
would be a request from an application to a cash dispenser to retract items where the dispenser hardware does not
have that capability; the Service Provider recognizes the command but, since the cash dispenser it is managing is
unable to fulfil the request, returns this error.
The requested capability is not defined for the class of Service Providers by the XFS specification. In this case, a
WFS_ERR_INVALID_COMMAND for Execute commands or WFS_ERR_INVALID_CATEGORY error for Info
commands error is returned to the calling application.
This design allows implementation of applications that can be used with a range of services that provide differing
subsets of the functionalities that are defined for their service class. Applications may use the WFSGetInfo and
WFSAsyncGetInfo commands to inquire about the capabilities of the service they are about to use, and modify
their behavior accordingly, or they may use functions and then deal with error returns to make decisions as to how
to use the service.
2. Cash Dispensers
This specification describes the functionality of an XFS compliant Cash Dispenser Module (CDM) Service
Provider. It defines the service-specific commands that can be issued to the Service Provider using the
WFSGetInfo, WFSAsyncGetInfo, WFSExecute and WFSAsyncExecute functions.
Persistent values are maintained through power failures, open sessions, close session and system resets.
This specification covers the dispensing of items. An “item” is defined as any media that can be dispensed and
includes coupons, documents, bills and coins. However, if coins and bills are both to be dispensed separate Service
Providers must be implemented for each.
All currency parameters in this specification are expressed as a quantity of minimum dispense units, as defined in
the description of the WFS_INF_CDM_CURRENCY_EXP command.
There are two types of CDM: Self-Service CDM and Teller CDM. A Self-Service CDM operates in an automated
environment, while a Teller CDM has an operator present. The functionality provided by the following commands
is only applicable to a Teller CDM:
WFS_CMD_CDM_SET_TELLER_INFO
WFS_INF_CDM_TELLER_INFO
It is possible for the CDM to be part of a compound device with the Cash-In Module (CIM). This CIM\CDM
combination is referred to throughout this specification as a “Cash Recycler”. For details of the CIM interface see
[Ref. 3].
If the device is a Cash Recycler then, if cash unit exchanges are required on both interfaces, the exchanges cannot
be performed concurrently. An exchange on one interface must be complete (the
WFS_CMD_CDM_END_EXCHANGE must have completed) before an exchange can start on the other interface.
The WFS_ERR_CDM_EXCHANGEACTIVE error code will be returned if the correct sequence is not adhered to.
The CIM interface can be used for all exchange operations on recycle devices, and the CIM interface should be
used if the device has recycle units of multiple currencies and/or denominations (including multiple note identifiers
associated with the same denomination).
The event WFS_SRVE_CDM_COUNTS_CHANGED will be posted if an operation on the CIM interface affects
the cash unit counts which are available through the CDM interface.
The following commands on the CIM interface may affect the CDM counts:
WFS_CMD_CIM_CASH_IN
WFS_CMD_CIM_CASH_IN_END
WFS_CMD_CIM_CASH_IN_ROLLBACK
WFS_CMD_CIM_RETRACT
WFS_CMD_CIM_SET_CASH_IN_UNIT_INFO
WFS_CMD_CIM_END_EXCHANGE
WFS_CMD_CIM_RESET
WFS_CMD_CIM_REPLENISH
WFS_CMD_CIM_CASH_UNIT_COUNT
3. References
1. XFS Application Programming Interface (API)/Service Provider Interface ( SPI), Programmer’s Reference,
Revision 3.4050
2. ISO 4217 at http://www.iso.orghttp://www.iso.org
3. XFS Cash-In Module Device Class Interface, Programmer’s Reference, Revision 3.4050
4. Note Classification
Notes are classified by the XFS CDM specification according to the following definitions:
1. Level 1 – Note is not recognized.
2. Level 2 – Recognized counterfeit note.
3. Level 3 – Suspected counterfeit note.
4. Level 4 – Recognized note that is identified as genuine. This includes notes which are fit or unfit for
recycling.
This definition allows support for legislative note handling standards that may exist in various countries and
economic regions. Local requirements or device capability may dictate that notes are not classified as level 2 and
level 3 and therefore counterfeit or suspect notes would be classified as level 1; the P6 string reported by
WFS_INF_CIM_CAPABILITIES lpszExtra reports whether notes are classified into all 4 levels.
The above classification levels can be used to support note handling functionality which includes:
1. The ability to remove counterfeit notes from circulation.
2. Reporting of unrecognized, recognized counterfeit and suspected counterfeit notes.
3. Creating and reporting of note signatures in order to allow back-tracing of notes.
A note’s classification can be changed based on the note’s serial number, currency and value by specifying a
blacklist or classification list. A blacklist reclassifies a matching note as level 2, whereas a classification list can be
used to re-classify a matching note to a lower level, including classifying a genuine note as unfit for dispensing.
Once reclassified, the note will be automatically handled according to the local country specific note handling
standard or legislation. Any reclassification will result in the normal events and behavior, for example a
WFS_EXEE_CDM_INFO_AVAILABLE event will reflect the note’s reclassification. Reclassification can be used
to make dynamic changes to note handling procedures without a software upgrade, enabling functionality such as
taking older notes out of circulation or handling of counterfeit notes on a local basis.
Reclassification cannot be used to change a note’s classification to a higher level, for example, a note recognized as
counterfeit by the device cannot be reclassified as genuine. In addition, it is not possible to re-classify a level 2 note
as level 1. No particular use case has been identified for reclassifying Level 3 and 4 notes as level 1, but there is no
reason to restrict this reclassification.
Blacklists can be specified using WFS_CMD_CDM_SET_BLACKLIST and retrieved using
WFS_INF_CDM_GET_BLACKLIST. Classification lists can be specified using
WFS_CMD_CDM_SET_CLASSIFICATION_LIST and retrieved using
WFS_INF_CDM_GET_CLASSIFICATION_LIST. A classification list is a superset of the blacklist; any items
specified as level 2 in the classification list are considered part of the blacklist. However, it is not recommended
that both sets of commands are used by a single application, as it may lead to overlap and confusion.
The blacklist or classification list functionality can use a mask to specify serial numbers. The mask is defined as
follows: A '?' character (0x003F) is the wildcard used to match a single Unicode character, and a '*' character
(0x002A) is the wildcard used to match one or more Unicode characters.
For example, “S8H9??16?4” would represent a match for the serial numbers “S8H9231654” and “S8H9761684”. A
mask of “HD90*2” would be used in order to match serial numbers that begin with “HD90” and end with “2”, for
example “HD9028882”, “HD9083276112”. Note that the mask can only use one asterisk, and if a real character is
required then it must be preceded by a backslash, for example: '\\' for a backslash, '\*' for an asterisk or '\?' for a
question mark.
Note that this flexibility means that it is possible to overlap definitions, for example “HD90*” and “HD902*”
would both match on the serial number HD9028882”.
5. Info Commands
5.1 WFS_INF_CDM_STATUS
Description This command is used to obtain the status of the CDM. It may also return vendor-specific status
information.
Input Param None.
Output Param LPWFSCDMSTATUS lpStatus;
typedef struct _wfs_cdm_status
{
WORD fwDevice;
WORD fwSafeDoor;
WORD fwDispenser;
WORD fwIntermediateStacker;
LPWFSCDMOUTPOS *lppPositions;
LPSTR lpszExtra;
DWORD dwGuidLights[WFS_CDM_GUIDLIGHTS_SIZE];
WORD wDevicePosition;
USHORT usPowerSaveRecoveryTime;
WORD wAntiFraudModule;
} WFSCDMSTATUS, *LPWFSCDMSTATUS;
fwDevice
Supplies the state of the CDM. However, an fwDevice status of WFS_CDM_DEVONLINE does
not necessarily imply that dispensing can take place: the value of the fwDispenser field must be
taken into account and - for some vendors - the state of the safe door (fwSafeDoor) may also be
relevant. The state of the CDM will have one of the following values:
Value Meaning
WFS_CDM_DEVONLINE The device is online. This is returned when
the dispenser is present and operational.
WFS_CDM_DEVOFFLINE The device is offline (e.g. the operator has
taken the device offline by turning a switch).
WFS_CDM_DEVPOWEROFF The device is powered off or physically not
connected.
WFS_CDM_DEVNODEVICE The device is not intended to be there, e.g.
this type of self service machine does not
contain such a device or it is internally not
configured.
WFS_CDM_DEVHWERROR The device is inoperable due to a hardware
error.
WFS_CDM_DEVUSERERROR The device is present but a person is
preventing proper device operation.
WFS_CDM_DEVBUSY The device is busy and unable to process an
execute command at this time.
WFS_CDM_DEVFRAUDATTEMPT The device is present but is inoperable
because it has detected a fraud attempt.
WFS_CDM_DEVPOTENTIALFRAUD The device has detected a potential fraud
attempt and is capable of remaining in
service. In this case the application should
make the decision as to whether to take the
device offline.
fwSafeDoor
Supplies the state of the safe door as one of the following values:
Value Meaning
WFS_CDM_DOORNOTSUPPORTED Physical device has no safe door or safe door
state reporting is not supported.
WFS_CDM_DOOROPEN Safe door is open.
WFS_CDM_DOORCLOSED Safe door is closed.
WFS_CDM_DOORUNKNOWN Due to a hardware error or other condition,
the state of the safe door cannot be
determined.
fwDispenser
Supplies the state of the dispenser’s logical cash units as one of the following values:
Value Meaning
WFS_CDM_DISPOK All cash units present are in a good state.
WFS_CDM_DISPCUSTATE One or more of the cash units is in a low,
empty, inoperative or manipulated condition.
Items can still be dispensed from at least one
of the cash units.
WFS_CDM_DISPCUSTOP Due to a cash unit failure dispensing is
impossible. No items can be dispensed
because all of the cash units are in an empty,
inoperative or manipulated condition. This
state may also occur when a reject/retract
cash unit is full or no reject/retract cash unit
is present, or when an application lock is set
on every cash unit which can be locked.
WFS_CDM_DISPCUUNKNOWN Due to a hardware error or other condition,
the state of the cash units cannot be
determined.
fwIntermediateStacker
Supplies the state of the intermediate stacker. These bills are typically present on the intermediate
stacker as a result of a retract operation or because a dispense has been performed without a
subsequent present. Possible values for this field are:
Value Meaning
WFS_CDM_ISEMPTY The intermediate stacker is empty.
WFS_CDM_ISNOTEMPTY The intermediate stacker is not empty. The
items have not been in customer access.
WFS_CDM_ISNOTEMPTYCUST The intermediate stacker is not empty. The
items have been in customer access. If the
device is a recycler then the items on the
intermediate stacker may be there as a result
of a previous cash-in operation.
WFS_CDM_ISNOTEMPTYUNK The intermediate stacker is not empty. It is
not known if the items have been in
customer access.
WFS_CDM_ISUNKNOWN Due to a hardware error or other condition,
the state of the intermediate stacker cannot
be determined.
WFS_CDM_ISNOTSUPPORTED The physical device has no intermediate
stacker.
lppPositions
Pointer to a NULL-terminated array of pointers to WFSCDMOUTPOS structures. There is one
structure for each position to which items can be dispensed or presented:
typedef struct _wfs_cdm_position
{
WORD fwPosition;
WORD fwShutter;
WORD fwPositionStatus;
WORD fwTransport;
WORD fwTransportStatus;
WORD fwJammedShutterPosition;
} WFSCDMOUTPOS, *LPWFSCDMOUTPOS;
fwPosition
Supplies the output position as one of the following values:
Value Meaning
WFS_CDM_POSLEFT Left output position.
WFS_CDM_POSRIGHT Right output position.
WFS_CDM_POSCENTER Center output position.
WFS_CDM_POSTOP Top output position.
WFS_CDM_POSBOTTOM Bottom output position.
WFS_CDM_POSFRONT Front output position.
WFS_CDM_POSREAR Rear output position.
fwShutter
Supplies the state of the shutter as one of the following values:
Value Meaning
WFS_CDM_SHTCLOSED The shutter is operational and is closed.
WFS_CDM_SHTOPEN The shutter is operational and is open.
WFS_CDM_SHTJAMMED The shutter is jammed and is not
operational. The field
fwJammedShutterPosition provides the
positional state of the shutter.
WFS_CDM_SHTUNKNOWN Due to a hardware error or other
condition, the state of the shutter cannot
be determined.
WFS_CDM_SHTNOTSUPPORTED The physical device has no shutter or
shutter state reporting is not supported.
fwPositionStatus
Returns information regarding items which may be at the output position. If the device is a
recycler it is possible that the output position will not be empty due to a previous cash-in
operation. The possible values of this field are:
Value Meaning
WFS_CDM_PSEMPTY The output position is empty.
WFS_CDM_PSNOTEMPTY The output position is not empty.
WFS_CDM_PSUNKNOWN Due to a hardware error or other
condition, the state of the output position
cannot be determined.
WFS_CDM_PSNOTSUPPORTED The device is not capable of reporting
whether or not items are at the output
position.
fwTransport
Supplies the state of the transport mechanism as one of the following values. The transport is
defined as any area leading to or from the position:
Value Meaning
WFS_CDM_TPOK The transport is in a good state.
WFS_CDM_TPINOP The transport is inoperative due to a
hardware failure or media jam.
WFS_CDM_TPUNKNOWN Due to a hardware error or other
condition the state of the transport cannot
be determined.
WFS_CDM_TPNOTSUPPORTED The physical device has no transport or
transport state reporting is not supported.
fwTransportStatus
Returns information regarding items which may be on the transport. If the device is a recycler
device it is possible that the transport will not be empty due to a previous cash-in operation.
The possible values of this field are:
Value Meaning
WFS_CDM_TPSTATEMPTY The transport is empty.
WFS_CDM_TPSTATNOTEMPTY The transport is not empty.
WFS_CDM_TPSTATNOTEMPTYCUST Items which a customer has had access to
are on the transport.
WFS_CDM_TPSTATNOTEMPTY_UNK Due to a hardware error or other
condition it is not known whether there
are items on the transport.
WFS_CDM_TPSTATNOTSUPPORTED The device is not capable of reporting
whether items are on the transport.
fwJammedShutterPosition
Returns information regarding the position of the jammed shutter. The possible values of this
field are:
Value Meaning
WFS_CDM_SHUTTERPOS_NOTSUPPORTED The physical device has no shutter or
the reporting of the position of a
jammed shutter is not supported.
WFS_CDM_SHUTTERPOS_NOTJAMMED The shutter is not jammed.
WFS_CDM_SHUTTERPOS_OPEN The shutter is jammed, but fully open.
WFS_CDM_SHUTTERPOS_PARTIALLY_OPEN The shutter is jammed, but partially
open.
WFS_CDM_SHUTTERPOS_CLOSED The shutter is jammed, but fully
closed.
WFS_CDM_SHUTTERPOS_UNKNOWN The position of the shutter is
unknown.
lpszExtra
Pointer to a list of vendor-specific, or any other extended, information. The information is
returned as a series of “key=value” strings so that it is easily extensible by Service Providers.
Each string is null-terminated, with the final string terminating with two null characters. An
empty list may be indicated by either a NULL pointer or a pointer to two consecutive null
characters.
dwGuidLights [.]
Specifies the state of the guidance light indicators. The elements of this array can be accessed by
using the predefined index values specified for the dwGuidLights [ ] field in the capabilities.
Vendor specific guidance lights are defined starting from the end of the array. The maximum
guidance light index is WFS_CDM_GUIDLIGHTS_MAX.
Specifies the state of the guidance light indicator as
WFS_CDM_GUIDANCE_NOT_AVAILABLE, WFS_CDM_GUIDANCE_OFF or a
combination of the following flags consisting of one type B, optionally one type C and optionally
one type D.
Value Meaning Type
WFS_CDM_GUIDANCE_NOT_AVAILABLE The status is not
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...