SIST-TP CWA 16926-61:2023

SLOVENSKI STANDARD
SIST CWA 16926-61:2023
01-april-2023
Specifikacija vmesnika razširitev za finančne storitve (XFS), izdaja 3.50 - 61. del:
Vmesnik za programiranje aplikacij (API) - Vmesnik ponudnika storitev (SPI) -
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 61:
Application Programming Interface (API) - Service Provider Interface (SPI) -
Programmer's Reference - Migration from Version 3.40 (CWA 16926:2000) to Version
3.50 (this CWA)
Ta slovenski standard je istoveten z: CWA 16926-61: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-61:2023 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

SIST CWA 16926-61:2023
SIST CWA 16926-61:2023
CEN
CWA 16926-61
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 61: Application
Programming Interface (API) - Service Provider Interface
(SPI) - Programmer's Reference - Migration from Version
3.40 (CWA 16926:2000) 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-61:2023 E
SIST CWA 16926-61:2023
Table of Contents
European Foreword . 6
1 Introduction . 10
1.1 Background to Release 3.50 . 10
2 References . 11
3 XFS (eXtensions for Financial Services) Overview . 12
3.1 Architecture . 13
3.2 API and SPI Summary . 15
3.3 Device Classes . 16
3.4 Unicode Encoding Summary . 17
4 Architectural and Implementation Issues . 18
4.1 The XFS Manager . 19
4.2 Service Providers . 20
4.2.1 Service Provider Functionality .20
4.2.2 Service Provider “Packaging” .20
4.3 Asynchronous, Synchronous and Immediate Functions . 21
4.3.1 Asynchronous Functions .21
4.3.2 Synchronous Functions .21
4.3.3 Immediate Functions .22
4.4 Processing API Functions . 23
4.5 Opening a Session . 24
4.6 Closing a Session . 25
4.7 Configuration Information . 26
4.8 Exclusive Service and Device Access . 30
4.8.1 Lock Policy for Independent Devices .30
4.8.2 Compound Devices .31
4.9 Timeout . 33
4.10 Function Status Return . 34
4.11 Notification Mechanisms - Registering for Events . 35
4.12 Application Processes, Threads and Blocking Functions . 37
4.13 Vendor Dependent Mode . 39
4.14 Memory Management . 40
4.15 Command Synchronization . 42
4.16 Binary Interface . 43
5 Application Programming Interface (API) Functions. 44
5.1 WFSCancelAsyncRequest . 46
5.2 WFSCancelBlockingCall . 47
5.3 WFSCleanUp . 48
5.4 WFSClose . 49
SIST CWA 16926-61:2023
5.5 WFSAsyncClose . 50
5.6 WFSCreateAppHandle . 51
5.7 WFSDeregister . 52
5.8 WFSAsyncDeregister . 53
5.9 WFSDestroyAppHandle . 55
5.10 WFSExecute . 56
5.11 WFSAsyncExecute. 58
5.12 WFSFreeResult . 60
5.13 WFSGetInfo . 61
5.14 WFSAsyncGetInfo . 63
5.15 WFSIsBlocking . 65
5.16 WFSLock . 66
5.17 WFSAsyncLock . 68
5.18 WFSOpen . 70
5.19 WFSAsyncOpen . 73
5.20 WFSRegister . 76
5.21 WFSAsyncRegister . 77
5.22 WFSSetBlockingHook . 79
5.23 WFSStartUp . 80
5.24 WFSUnhookBlockingHook . 82
5.25 WFSUnlock . 83
5.26 WFSAsyncUnlock . 84
6 Service Provider Interface (SPI) Functions . 85
6.1 WFPCancelAsyncRequest . 86
6.2 WFPClose . 87
6.3 WFPDeregister . 88
6.4 WFPExecute . 90
6.5 WFPGetInfo . 92
6.6 WFPLock . 94
6.7 WFPOpen . 95
6.8 WFPRegister . 98
6.9 WFPSetTraceLevel . 99
6.10 WFPUnloadService . 100
6.11 WFPUnlock . 101
7 Support Functions . 102
7.1 WFMAllocateBuffer . 102
7.2 WFMAllocateMore . 103
7.3 WFMFreeBuffer . 104
7.4 WFMGetTraceLevel . 105
7.5 WFMKillTimer . 106

SIST CWA 16926-61:2023
7.6 WFMOutputTraceData . 107
7.7 WFMReleaseDLL . 108
7.8 WFMSetTimer . 109
7.9 WFMSetTraceLevel . 110
8 Configuration Functions . 112
8.1 WFMCloseKey . 112
8.2 WFMCreateKey . 113
8.3 WFMDeleteKey . 114
8.4 WFMDeleteValue . 115
8.5 WFMEnumKey . 116
8.6 WFMEnumValue . 117
8.7 WFMOpenKey . 118
8.8 WFMQueryValue . 119
8.9 WFMSetValue . 120
9 Data Structures . 121
9.1 WFSRESULT . 121
9.2 WFSVERSION . 122
10 Messages . 123
10.1 Command Completions and Events . 123
10.1.1 Command Completion Messages .123
10.1.2 Event Messages .123
10.2 WFS_TIMER_EVENT . 124
10.3 WFS_SYSE_DEVICE_STATUS . 125
10.4 WFS_SYSE_UNDELIVERABLE_MSG. 126
10.5 WFS_SYSE_APP_DISCONNECT . 127
10.6 WFS_SYSE_HARDWARE_ERROR, WFS_SYSE_SOFTWARE_ERROR,
WFS_SYSE_USER_ERROR and WFS_SYSE_FRAUD_ATTEMPT . 128
10.7 WFS_SYSE_LOCK_REQUESTED . 130
10.8 WFS_SYSE_VERSION_ERROR . 131
11 Error Codes . 132
12 XFS End to End (E2E) Authentication . 135
12.1 XFS E2E General description . 135
12.2 Determining Specific E2E Authentication Requirements . 135
13 Common GetInfo, Execute Commands and Messages . 136
13.1 Common GetInfo Commands . 136
13.1.1 WFS_INF_API_TRANSACTION_STATE .136
13.1.2 WFS_INF_API_SERVICE_INFO .137
13.1.3 WFS_INF_API_SECURE_QUERY .141
13.1.4 WFS_INF_API_SYNC_PICTURE.143
13.2 Common Execute Commands . 145
13.2.1 WFS_CMD_API_SET_TRANSACTION_STATE .145
SIST CWA 16926-61:2023
13.2.2 WFS_CMD_API_GET_COMMAND_NONCE.146
13.2.3 WFS_CMD_API_SECURE_COMMAND .147
13.2.4 WFS_CMD_API_CLEAR_COMMAND_NONCE .149
13.2.5 WFS_CMD_API_SYNC_PICTURE .150
13.3 Common Events . 151
13.3.1 WFS_SRVE_API_STATUS_CHANGED .151
13.3.2 WFS_EXEE_API_ERROR_INFO .152
13.3.3 WFS_SRVE_API_NONCE_CLEARED .153
13.3.4 WFS_SRVE_API_SYNC_PICTURE .154
14 Appendix A - Planned Enhancements and Extensions . 155
14.1 Event and System Management . 156
15 Appendix B - XFS Workshop Contacts . 157
16 Appendix C - ATM Devices Synchronization Flow . 158
16.1 Synchronized Media Ejection . 158
17 Appendix D – Win64 Migration Considerations . 159
18 Appendix E - C-Header files . 160
18.1 XFSAPI.H . 160
18.2 XFSADMIN.H . 169
18.3 XFSCONF.H . 170
18.4 XFSSPI.H . 172

SIST CWA 16926-61: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-01, but this does not guarantee, either explicitly or implicitly, its correctness.
Users of CWA 16926-01 should be aware that neither the Workshop participants, nor CEN can be held liable for
SIST CWA 16926-61:2023
damages or losses of any kind whatsoever which may arise from its application. Users of CWA 16926-01 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-61: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-61: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 API 3.10 Migration document.
3.20 March 2, 2011 For a description of changes from version 3.10 to version
3.20 see the API 3.20 Migration document.
3.30 March 19, 2015 For a description of changes from version 3.20 to version
3.30 see the API 3.30 Migration document.
3.40 December 06, 2019 For a description of changes from version 3.30 to version
3.40 see the API 3.40 Migration document.
3.50 November 18, 2022 For a description of changes from version 3.40 to version
3.50 see the API 3.50 Migration document.

SIST CWA 16926-61: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
SIST CWA 16926-61:2023
2 References
1. XFS Service Classes Definition, Programmer’s Reference Revision 3.40
2. The Unicode Standard, Version 5.0, released on 9 November 2006. ISBN 0321480910
1. XFS Service Classes Definition, Programmer’s Reference Revision 3.50
2. The Unicode Standard, Version 5.0, released on 9 November 2006. ISBN 0321480910
3. End-to-End (E2E) for XFS/XFS4IoT Programmer's Reference v1.0, CEN CWA 17852

SIST CWA 16926-61:2023
3 XFS (eXtensions for Financial Services) Overview
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.
SIST CWA 16926-61:2023
3.1 Architecture
The architecture of the Extensions for Financial Services (XFS) system is shown below.

Figure 2.1 - Extensions for Financial Services Architecture
The applications communicate with Service Providers, via the Extensions for Financial Services Manager, using the
API set. Most of these APIs can be invoked either "synchronously" (the Manager causes the application to wait
until the API's function is completed) or "asynchronously" (the application regains control immediately, while the
function is performed in parallel).
The common deliverable in all implementations of this Extensions for Financial Services specification is the
Extensions for Financial Services Manager, which maps the specified API to the corresponding SPI, then routes this
request to the appropriate Service Provider. Multiple implementations of the XFS Manager exist from different
vendors. For the definition of the binary interface, see section 4.16.
The Manager uses the configuration information to route the API call (made to a "logical service" or a "logical
device") to the proper Service Provider entry point (which is always local, even though the device or service that is
the final target may be remote). Note that even though the API calls may be either synchronous or asynchronous,
the SPI calls are always asynchronous.
The developers of financial services to be used via XFS and the manufacturers of financial peripherals will be
responsible for the development and distribution of Service Providers for their services and devices. A setup routine
for each device or service will also be necessary to define the appropriate configuration information. This
information will allow an application to request capability and status information about the devices and services
available at any point in time.
The primary functions of the Service Providers are to:
• Translate generic (e.g. forms-based) service requests to service-specific commands.
• Route the requests to either a local service or device, or to one on a remote system, effectively defining a
peer-to-peer interface among Service Providers.
• Arbitrate access by multiple applications to a single service or device, providing exclusive access when
requested.
• Manage the hardware interfaces to services or devices.
• Manage the asynchronous nature of the services and devices in an appropriate manner, always presenting
this capability to the XFS Manager and the applications via Windows messages.
The system design supports solution of complex problems, often not addressed by current systems, by providing for
maximum flexibility in all its capabilities:

SIST CWA 16926-61:2023
• Multiple Service Providers, developed by multiple vendors, can coexist in a single system and in a
network. This is ensured by a standard messaging/data interface and a standard binary interface for the
XFS Manager.
• The service class definition is based on the logical functionalities of the service, with no assumption being
made as to the physical configuration. A physical device that includes multiple distinct physical
capabilities (referred to as a "compound device" in this specification) is treated as several logical services;
the Service Provider resolves any conflicts. Note also that a logical service may include multiple physical
devices (for example, a cash dispenser consisting of a note dispenser and coin dispenser).
• Similarly, a physical device may be shared between two or more users (e.g. tellers), and the physical
device synchronization is managed at the Service Provider level.
• The API definition and associated services provide time-out functionality to allow applications to avoid
deadlock of the type that can occur if two applications try to get exclusive access to multiple services at
the same time.
• The architecture is designed to provide a framework for future development of network and system
monitoring, measurement, and management.
Note that Figure 2.1 is a high level view of the architecture and, in particular, it makes no distinction between
Service Providers and the services they manage. This specification focuses on Service Providers rather than on
services, because the way a Service Provider communicates with a service is a vendor-specific internal design issue
that applications and the XFS Manager are unaware of. In fact, there are many different ways that Service Providers
can make services available to applications. Hence, this specification refers primarily to the Service Providers, since
these are the modules with which the XFS Manager communicates. There are occasional references to 'service'
where this is appropriate.
Example
Figure 2.2 below shows an XFS system supporting a set of financial peripherals. Note that in this framework the
XFS Manager interfaces directly with a set of Service Providers that interface directly with the physical devices.
Thus, the Service Providers are shown as implementing the Service Provider, service, and device driver functions,
although these are more likely to be two or more separate layers. Many other configurations are possible.
WorkStation 1 WorkStation 2 WorkStation 3
Application Application Application
Configuration Configuration Configuration
WOSA/XFS API WOSA/XFS API WOSA/XFS API
Information Information Information
WOSA/XFS WOSA/XFS WOSA/XFS
Manager Manager Manager
WOSA/XFS SPI WOSA/XFS SPI WOSA/XFS SPI
Passbook Passbook Passbook Passbook
Magnetic
Printer Printer Printer Printer
Card Reader
Service
Service Service Service
Service Provider
Provider Provider Provider Provider
Vendor Y
Vendor X Vendor Y Vendor Y Vendor X
Passbook Passbook Magnetic Passbook
Printer Printer Card Reader Printer
Vendor X Vendor Y Vendor Y Vendor X

Figure 2.2 - An XFS architecture example for a branch office banking system.
It should also be noted that one vendor's Service Providers are not necessarily compatible with another vendor's, as
shown in Figure 2.2. If one application has to access the same service class as implemented by different vendors, a
Service Provider is installed for each vendor.
SIST CWA 16926-61:2023
3.2 API and SPI Summary
Sections 5 through 8 of this document present the interfaces that allow a financial application to communicate in a
standard fashion with financial services and devices. The functions are at a sufficiently high level to allow for
seamless redirection to other parts of the underlying operating system. A printer, for example, might rely on a set of
services provided by the operating system, but in order to handle the unique characteristics of a financial printer and
application, the Service Provider would pre-process the command, then redirect the derived commands to the
operating system's printing services. In other implementations, the printer might be supported entirely by XFS
service mechanisms, and not use the operating system printing services in any way.
The API is structured as sets of:
Basic functions, such as StartUp/CleanUp, Open/Close, Lock/Unlock, and Execute, that are common
to all the Extensions for Financial Services device/service classes,
Administration functions, such as device initialization, reset, suspend or resume, used for managing
devices and services, and
Specific commands, used to request information about a service/device, and to initiate device/service-
specific functions; these are sent to devices and services as parameters of the GetInfo and Execute basic functions.
These service-specific commands are specified in a set of separate specifications, one for each service class.
To the maximum extent possible, the syntax of specific commands that are used with multiple device/service
classes is kept consistent across all devices. A primary objective is to standardize function codes and structures for
the widest possible variety of devices.
The SPI is kept as similar as possible to the API. Some commands are processed exclusively by the XFS Manager,
and so are not in the SPI, and there are minor differences in the specific parameters passed at the two interface
levels.
A typical scenario showing the usage of the APIs is shown below. This example illustrates the functions used to
print a form.
• StartUp (connects the application to the XFS Manager, including version negotiation)
• Open (establishes a session between the application and the Service Provider)
• Register (specifies the messages that the application should receive from the Service
Provider)
• Lock (obtains exclusive access to the service by the application)
• multiple Execute functions, passing one or more specific commands:
• Print_Form
• etc.
• Unlock (releases exclusive access to the service by the application)
• Deregister (specifies that the application should no longer receive messages from the Service
Provider)
• Close (ends the session between the application and the Service Provider)
• CleanUp (disconnects the application from the XFS Manager)
Note that within a session (defined by Open and Close), an application may at any time change the classes of
messages it wishes to receive from the Service Provider (using Register), and may either Lock the se
...