CEN/WS XFS - Extensions for financial services (XFS) interface specification

This specification shows the modifications made to version 3.40 of CWA 16926-11 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-6 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-5 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-9 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-18 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-14 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-4 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-15 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-8 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-10 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-16 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-12 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-3 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-1 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-13 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-7 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-19 in version 3.50.

This specification shows the modifications made to version 3.40 of CWA 16926-17 in version 3.50.

This CWA describes the functions provided by a generic identification card reader/writer service (IDC). These descriptions include definitions of the service-specific commands that can be issued, using the WFSAsyncExecute, WFSExecute, WFSGetInfo and WFSAsyncGetInfo functions.
This service allows for the operation of the following categories of units:
•   motor driven card reader/writer
•   pull through card reader (writing facilities only partially included)
•   dip reader
•   contactless chip card readers
•   permanent chip card readers (each chip is accessed through a unique logical service)

Exception XML

This specification describes the XFS service class for Item Processing Modules (IPM). The specification of this service class includes definitions of the service-specific commands that can be issued, using the WFSAsyncExecute, WFSExecute, WFSGetInfo and WFSAsyncGetInfo functions.
This service class is currently defined only for self service devices.
In the U.S., checks are always encoded in magnetic ink for reading by Magnetic Ink Character Recognition (MICR), and a single font is always used. In Europe some countries use MICR and some use Optical Character Recognition (OCR) character sets, with different fonts, for their checks.
Item Processing Modules accept one or more media items (Checks, Giros, etc.) and process these items according to application requirements. The IPM class supports devices that can handle a single item as well as those devices that can handle bunches of items. The following are the three principal device types:
• Single Item: can accept and process a single item at a time.
• Multi-Item Feed with no stacker (known as an escrow in some environments): can accept a bunch of media from the customer but each item has to be processed fully (i.e. deposited in a bin or returned) before the next item can be processed.
• Multi-Item Feed with a stacker: can accept a bunch of media from the customer and all items can be processed together.
The IPM class provides applications with an interface to control the following functions (depending on the capabilities of the specific underlying device):
• Capture an image of the front of an item in multiple formats and bit depths.
• Capture an image of the back of an item in multiple formats and bit depths.
• Read the code line of an item using MICR reader.
• Read the code line of an item using OCR.
• Endorse (print text) on an item.
• Stamp an item.
• Return an item to the customer.
• Deposit an item in a bin.
• Retract items left by the customer.
The IPM device class uses the concept of a Media-In transaction to track and control a customer’s interaction with the device. A Media-In transaction consists of one or more WFS_CMD_IPM_MEDIA_IN commands. The transaction is initiated by the first WFS_CMD_IPM_MEDIA_IN command and remains active until the transaction is either confirmed through WFS_CMD_IPM_MEDIA_IN_END, or terminated by WFS_CMD_IPM_MEDIA_IN_ROLLBACK, WFS_CMD_IPM_RETRACT_MEDIA or WFS_CMD_IPM_RESET. While a transaction is active the WFS_INF_IPM_TRANSACTION_STATUS command reports the status of the current transaction. When a transaction is not active the WFS_INF_IPM_TRANSACTION_STATUS command reports the status of the last transaction as well as some current status values.
There are primarily two types of devices supported by the IPM, those devices with a stacker and those without.
In this the specification the terms “long edge” and “short edge” are used to describe the orientation of a check and length of its edges. The diagram below illustrates these definitions.

This specification describes the functionality of the services provided by Alarms (ALM) under XFS, by defining the service-specific commands that can be issued, using the WFSGetInfo, WFSAsyncGetInfo, WFSExecute and WFSAsyncExecute functions. This section describes the functionality of an Alarm (ALM) service that applies to both attended and unattended (self-service) devices.
The Alarm device class is provided as a separate service due to the need to set or reset an Alarm when one or more logical services associated with an attended CDM or unattended (self-service) device are locked. Because logical services can be locked by the application the Alarm is implemented in a separate device class to ensure that a set (trigger) or reset operation can be performed at any time.

This specification describes the functionality of the services provided by the Card Dispenser (CRD) device class under XFS, by defining the service-specific commands that can be issued, using the WFSGetInfo, WFSAsyncGetInfo, WFSExecute and WFSAsyncExecute functions.
A Card Dispenser is used to dispense a single card to a consumer from one or more bins. Most card dispensers also have the ability to retain a card to a bin.

This specification describes the functionality of the services provided by text terminal unit (TTU) services under XFS, by defining the service-specific commands that can be issued, using the WFSGetInfo, WFSAsyncGetInfo, WFSExecute and WFSAsyncExecute functions.
This section describes the functions provided by a generic Text Terminal Unit (TTU) service. A Text Terminal Unit is a text i/o device, which applies both to ATM operator panels and to displays incorporated in devices such as PIN pads and printers. This service allows for the following categories of functions:
•   Forms oriented input and output
•   Direct display output
•   Keyboard input
•   LED settings and control
All position indexes are zero based, where column zero, row zero is the top-leftmost position.

This specification describes the functionality of a Barcode Reader (BCR) 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 extension to XFS specifications defines the functionality of BCR service.
A Barcode Reader scans barcodes using any scanning technology. The device logic converts light signals or image recognition into application data and transmits it to the host system.
The basic operation of the Barcode Reader is managed using WFSExecute/WFSAsyncExecute functions.
When an application wants to read a barcode, it issues a WFS_CMD_BCR_READ command to prepare the scanner to read any barcode presented to it. When a document is presented to the BCR and a barcode type is recognized, a completion event is received which contains the barcode data that has been read.

This specification describes the functionality of the services provided by banking printers and scanning devices under XFS, focusing on the following areas:
•   application programming for printing
•   print document definition
•   integration with the Windows architecture
•   scanning images for devices such as check scanners
These descriptions include definitions of the service-specific commands that can be issued, using the WFSAsyncExecute, WFSExecute, WFSGetInfo and WFSAsyncGetInfo functions.
The requirements for printing in banking applications are significantly different from those of the conventional PC environment, and the XFS support delivers the foundation for financial application printing, including:
•   Controlled access to shared printers
The banking printers can be shared between workstations and the XFS layer provides the ability for the application to manage ownership of a print device. This allows an application to identify the operator granted control of the printer, and to ensure that a teller printing multiple documents is not interrupted by work for other applications.
•   Application controlled printing
In the banking environment, it is necessary for the application to receive positive feedback on the availability of print devices, and the success or failure of individual print operations. The XFS printer support provides a standard mechanism for application retrieval of this status information.
•   Management of printing peripherals
Distributed banking networks require the ability to track the availability and failure of printing peripherals on a branch and system-wide basis. Through the XFS WFSRegister function monitoring programs can collect error alerts from the banking printers.
•   Vendor independent API and document definition
All of the XFS peripheral implementations are designed around a standardized family of APIs to allow application code portability across vendor hardware platforms. With printers, it is also recognized that banks invest a significant amount of resource in the authoring of print documents. The XFS printer service class is implemented around a forms model which also standardizes the basic document definition. This extends the investment protection provided by XFS compliant systems to include this additional part of the application development.
- Windows printing integration
It is possible for a banking printer to offer printing capabilities that can be accessed by non-banking specific applications, such as general office productivity packages. This would not, for example, be true for a receipt printer, but it could be the case for a device with document printing capabilities. A vendor may choose an XFS implementation that allows both types of applications (XFS and Windows applications using the Windows printing subsystem) to share the printing devices. The vendor should specify any impact this approach has on XFS subsystem operation, such as error reporting.
Full implementation of the above features depends on the individual vendor-supplied Service Providers. This specification outlines the functionality and requirements for applications using the XFS printer and scanning services, and for the development of those services.

A key element of the Extensions for Financial Services is the definition of a set of APIs, a corresponding set of SPIs, and supporting services, providing access to financial services for Windows-based applications. The definition of the functionality of the services, of the architecture, and of the API and SPI sets, is outlined in this section, and described in detail in Sections 5 through 10.
The specification defines a standard set of interfaces such that, for example, an application that uses the API set to communicate with a particular Service Provider can work with a Service Provider of another conformant vendor, without any changes.
Although the Extensions for Financial Services define a general architecture for access to Service Providers from Windows-based applications, the initial focus of the CEN/XFS Workshop has been on providing access to peripheral devices that are unique to financial institutions. Since these devices are often complex, difficult to manage and proprietary, the development of a standardized interface to them from Windows-based applications and Windows operating systems can offer financial institutions and their solution providers immediate enhancements to productivity and flexibility.

This specification describes the functionality of the services provided by the Sensors and Indicators Unit (SIU) services under WOSA/XFS, by defining the service-specific commands that can be issued, using the WFSGetInfo, WFSAsyncGetInfo, WFSExecute and WFSAsyncExecute functions.
This section describes the functions provided by a generic Sensors and Indicators Unit service. This service allows for the operation of the following categories of ports:
•   Door sensors, such as cabinet, safe or vandal shield doors.
•   Alarm sensors, such as tamper, seismic or heat sensors.
•   Generic sensors, such as proximity or ambient light sensors.
•   Key switch sensors, such as the ATM operator switch.
•   Lamp/sign indicators, such as fascia light or audio indicators.
Note that while the SIU device class provides some basic support for guidance lights, extended guidance light functionality is specified in the individual device class specifications.  Therefore it is recommended that device guidance lights be supported and controlled via the individual device classes.
•   Auxiliary indicators.
•   Enhanced Audio Controller, for use by the partially sighted.
In self-service devices, the sensors and indicators unit is capable of dealing with external sensors, such as door switches, locks, alarms and proximity sensors, as well as external indicators, such as turning on lamps or heating.

This specification describes the XFS service class of check readers and scanners. Check image scanners are treated as a special case of check readers, i.e. image-enabled instances of the latter. This class includes devices with a range of features, from small hand-held read-only devices through which checks are manually swiped one at a time, to desktop units which automatically feed the check one at a time; recording the MICR data and check image, and endorse or encode the check. The specification of this service class includes definitions of the service-specific commands that can be issued, using the WFSAsyncExecute, WFSExecute, WFSGetInfo and WFSAsyncGetInfo functions.
In the U.S., checks are always encoded in magnetic ink for reading by Magnetic Ink Character Recognition (MICR), and a single font is always used. In Europe some countries use MICR and some use Optical Character Recognition (OCR) character sets, with different fonts, for their checks.
In all countries, typical fields found encoded on a check include the bank ID number and the account number. Part of the processing done by the bank is to also encode the amount on the check, usually done by having an operator enter the handwritten or typewritten face amount on a numeric keypad.
This service class is currently defined only for attended branch service.

This specification describes the functionality of the services provided by the Depository (DEP) services under XFS, by defining the service-specific commands that can be issued, using the WFSGetInfo, WFSAsyncGetInfo, WFSExecute and WFSAsyncExecute functions.
A Depository is used for the acceptance and deposit of media into the device or terminal. There are two main types of depository: an envelope depository for the deposit of media in envelopes and a night safe depository for the deposit of bags containing bulk media.
An envelope depository accepts media, prints on the media and deposits the media into a holding container or bin. Some envelope depositories offer the capability to dispense an envelope to the customer at the start of a transaction. The customer takes this envelope, fills in the deposit media, possibly inscribes it and puts it into the deposit slot. The envelope is then accepted, printed and transported into a deposit container.
The envelope dispense mechanism may be part of the envelope depository device mechanism with the same entry/exit slot or it may be a separate mechanism with separate entry/exit slot.
Envelopes dispensed and not taken by the customer can be retracted back into the device. When the dispenser is a separate mechanism the envelope is retracted back into the dispenser container. When the dispenser is a common mechanism the envelope is retracted into the depository container.
A night safe depository normally only logs the deposit of a bag and does not print on the media.

This specification describes the functionality of the services provided by the Camera (CAM) services under XFS, by defining the service-specific commands that can be issued, using the WFSGetInfo, WFSAsyncGetInfo, WFSExecute and WFSAsyncExecute functions.
Banking camera systems usually consist of a recorder, a video mixer and one or more cameras. If there are several cameras, each camera focuses a special place within the self-service area (e.g. the room, the customer or the cash tray). By using the video mixer it can be decided, which of the cameras should take the next photo. Furthermore data can be given to be inserted in the photo (e.g. date, time or bank code).
If there is only one camera that can switch to take photos from different positions, it is presented by the Service Provider as a set of cameras, one for each of its possible positions.

This specification describes the functionality of an XFS compliant Cash-In Module (CIM) 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 acceptance of items. An “item” is defined as any media that can be accepted and includes coupons, documents, bills and coins. However, if coins and bills are both to be accepted 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_CIM_CURRENCY_EXP command.
There are two types of CIM: Self-Service CIM and Teller CIM. A Self-Service CIM operates in an automated environment, while a Teller CIM has an operator present. The functionality provided by the following commands is only applicable to a Teller CIM:
WFS_CMD_CIM_SET_TELLER_INFO
WFS_INF_CIM_SET_TELLER_INFO
It is possible for the CIM to be part of a compound device with the Cash Dispenser Module (CDM). This CIM\CDM combination is referred to throughout this specification as a “cash recycler”. For details of the CDM 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_CIM_END_EXCHANGE must have completed) before an exchange can start on the other interface. The WFS_ERR_CIM_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 cash recycle devices, and this interface should be used for cash units of multiple currencies and/or denominations (including multiple note identifiers associated with the same denomination).
The event WFS_SRVE_CIM_COUNTS_CHANGED will be posted if an operation on the CDM interface affects the recycle cash unit counts which are available through the CIM interface.

This specification describes the functions provided by a generic card embossing unit (CEU). These descriptions include definitions of the service-specific commands that can be issued, using the WFSAsyncExecute, WFSExecute, WFSGetInfo and WFSAsyncGetInfo functions.
Embossing card units are generally viewed by XFS as compound devices with the following capabilities and features:
•   Embossing or printing of magnetic stripe card/ smart card.
•   Reading/encoding magnetic stripe tracks 1, 2, and 3.
•   Reading/writing smart card.
•   LCD display/ keypad input.
The XFS services supporting the various embossing card unit components are outlined as follows:
•   Embossing or printing of magnetic stripe card/ smart card - Card Embossing Unit (CEU) service.
•   Reading/encoding magnetic stripe tracks 1, 2, and 3 - ID Card (IDC) service, however when combined encoding/ embossing is performed the CEU service class is used.
•   Reading/writing smart cards - ID Card (IDC) service, however when combined writing smart card/ embossing is performed the CEU service class is used.
•   LCD display/ keypad input - Text Terminal Unit (TTU) service.

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 error for Execute commands or WFS_ERR_INVALID_CATEGORY error for Info commands 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.

This section describes the application program interface for personal identification number keypads (PIN pads) and other encryption/decryption devices. This description includes definitions of the service-specific commands that can be issued, using the WFSAsyncExecute, WFSExecute, WFSGetInfo and WFSAsyncGetInfo functions.
This section describes the general interface for the following functions:
•   Administration of encryption devices
•   Loading of encryption keys
•   Encryption / decryption
•   Entering Personal Identification Numbers (PINs)
•   PIN verification
•   PIN block generation (encrypted PIN)
•   Clear text data handling
•   Function key handling
•   PIN presentation to chipcard
•   Read and write safety critical Terminal Data from/to HSM
•   HSM and Chipcard Authentication
•   EMV 4.0 PIN blocks, EMV 4.0 public key loading, static and dynamic data verification
If the PIN pad device has local display capability, display handling should be handled using the Text Terminal Unit (TTU) interface.
The adoption of this specification does not imply the adoption of a specific security standard.
Important Notes:
•   This revision of this specification does not define all key management procedures; some key management is still vendor-specific.
•   Key space management is customer-specific, and is therefore handled by vendor-specific mechanisms.
•   Only numeric PIN pads are handled in this specification.
This specification also supports the Hardware Security Module (HSM), which is necessary for the German ZKA Electronic Purse transactions. Furthermore, the HSM stores terminal specific data.
This data will be compared against the message data fields (Sent and Received ISO8583 messages) prior to HSM-MAC generation/verification. HSM-MACs are generated/verified only if the message fields match the data stored.
Keys used for cryptographic HSM functions are stored separate from other keys. This must be considered when importing keys.
This version of PIN pad complies to the current ZKA specification 3.0. It supports loading and unloading against card account for both card types (Type 0 and Type 1) of the ZKA electronic purse. It also covers the necessary functionality for ‘Loading against other legal tender’.
Key values are passed to the API as binary hexadecimal values. When hex values are passed to the API within strings, the hex digits 0xA to 0xF can be represented by characters in the ranges ‘a’ to ‘f’ or ‘A’ to ‘F’.
The following commands and events were initially added to support the German ZKA standard, but may also be used for other national standards:
•   WFS_INF_PIN_HSM_TDATA
•   WFS_CMD_PIN_HSM_SET_TDATA
•   WFS_CMD_PIN_SECURE_MSG_SEND
•   WFS_CMD_PIN_SECURE_MSG_RECEIVE
•   WFS_CMD_PIN_GET_JOURNAL
•   WFS_SRVE_PIN_OPT_REQUIRED
•   WFS_CMD_PIN_HSM_INIT
•   WFS_SRVE_PIN_HSM_TDATA_CHANGED

This specification describes the XFS service class for Biometrics Device (BIO). The specification of this service class includes definitions of the service-specific commands.
Biometrics refers to metrics related to human characteristics and biology. Biometrics authentication can be used as a form of identification and/or access control. This is an overview of biometrics, as well as an introduction to the terminology used in this document. It introduces to XFS the concept of scanning a person’s biometric data in raw image form (raw biometric data), then processing it into a smaller more concise form that is easier to manage (biometric template data). The first scan of a user is called ENROLLMENT as the user is effectively being enrolled into a scheme by recording their biometric data. Thereafter subsequent scans of the user can be compared to the original data in order to verify who they say they are (VERIFICATION), or alternatively used to identify them as a specific individual (IDENTIFICATION).

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).

XFS4IoT has been identified as a successor to XFS 3.x to meet the following requirements:
1. Replace the XFS and J/XFS standards in the marketplace.
2. Target industries - Retail Banking.
3. Operating System Agnostic and Technology and Language Adaptable.
4. Multi-Vendor - Able to run common core high level functionality on multiple vendors hardware, while providing access to finer level device API granularity.
5. Flexibility - enabling new hardware topologies, device types and functionality to be rapidly adapted.
6. Support end to end application level security.
7. Should not prevent the use of a low resource computing environment.
8. Provide a good developer experience by providing a well-documented API that is easy to learn, is quick to market and reduces risk by exposing an unambiguous interface.
9. Leverage existing standards.
Within the overall requirements specified in the Charter, the opportunity has been taken to solve some of the issues with the 3.x interface while retaining all the same functionality:
1. Binary data structures makes adding new functionality difficult due to compatibility issues, leading to multiple redundant versions of the same command appearing in many of the existing device classes. To resolve this, a flexible text based approach has been adopted including the wide use of default parameters.
2. Compound devices have been difficult for applications to implement, particularly cash recycling. Addition of other shared functionality such as end to end security would make the use of compound devices more prevalent. Compound devices are removed in XFS4IoT, a single Service can support as many interfaces as required to support its requirements.
Migration from and to 3.x is a major consideration to support adoption of XFS4IoT. While a lot of duplication has been removed (for example the Card Reader interface has fewer commands and events defined than the equivalent 3.x IDC specification), all the same IDC commands and events can be implemented. In some cases, this is achieved by having shared common commands such as Common.Status which replaces all the 3.x WFS_INF_XXX_STATUS commands.