Exploring UI Automation Testing for Financial Devices Using CEN/XFS and Simulated Peripherals

1. Basic Concepts

1.1 UI Automation Testing – UI automation testing (also called UI testing) simulates real user operations from the user‑interface layer to verify application behavior. Common tools include QTP/UFT, Selenium, Waitr, and Appium for mobile.

1.2 CEN/XFS – XFS (extensions for financial services) is an international standard defined by the European Committee for Standardization (CEN) on top of Microsoft Windows Open System Architecture (WOSA). It provides standard APIs for Windows‑based applications to access financial devices such as card readers.

1.3 Simulated Peripherals – Software can simulate the response of real peripherals, allowing manual or automated testing on terminals without physical devices.

2. Difficulties in UI Automation Testing for Financial Devices

2.1 Architecture of Financial Devices – Typical devices (e.g., cash dispensers, ATMs) run on Windows and follow the CEN/XFS specification. Their software consists of an Application (AP), a Service Provider (SP), and device drivers. The XFS Manager comprises three DLLs: msxfs.dll, xfs_conf.dll, and xfs_supp.dll, exposing standard APIs to the AP and SP.

The XFS Manager offers a standard Application Programming Interface (API) upward and a standard Service Provider Interface (SPI) downward, allowing financial institutions to ignore driver implementation details while hardware vendors focus on the SPI.

2.2 Asynchronous Communication Principle – CEN/XFS uses Windows message passing for asynchronous processing. The basic flow is:

AP calls an asynchronous XFS Manager function (WFS series) to issue a command.

XFS Manager forwards the command to the SP via a WFP series function.

SP copies the command parameters but does not invoke the hardware driver yet; it returns WFS_SUCCESS or an error code.

WFS function returns the SP’s response to the AP.

AP may perform other tasks.

SP finally calls the hardware driver with the copied parameters, completes the operation, and sends a Complete event (WfsResult) back to the AP.

AP processes the Complete event, extracts data, and releases the WfsResult memory.

For critical steps (e.g., reading ID cards or magnetic stripe cards), the Complete event is essential; if an error occurs, the AP displays the error code, otherwise it waits for the Complete event before proceeding.

2.3 Specific Challenges for Cash‑Dispenser (超柜) Systems

The main difficulties are:

Many peripheral types (23 listed) are involved in critical transactions.

The “UI + Interface” approach (driving UI actions and then invoking hardware interfaces) contradicts the asynchronous communication model and proved infeasible.

Modifying the application source code is prohibited, making code‑comment workarounds unacceptable.

3. Design of UI Automation Testing Based on CEN/XFS

Two feasible technical solutions were identified:

3.1 Simulate XFS Manager – Modify the XFS Manager source to intercept calls to the SP and return simulated hardware data. Advantage: low integration cost (replace three DLLs). Disadvantage: source code of XFS Manager is restricted and hard to obtain.

3.2 Simulate Peripherals – Keep XFS Manager unchanged, intercept communication at the SP layer, and return pre‑configured hardware information (e.g., ID numbers, card data). Advantage: no need to modify XFS Manager. Disadvantage: requires building simulators for each peripheral, which is labor‑intensive.

3.2 Simulation Schemes for Typical Peripherals

First batch focuses on six key peripherals:

ID Card Module – Replace the SP program, pre‑configure multiple ID responses, and let the user select an ID to simulate.

Magnetic Stripe Reader – Similar approach with pre‑configured track data.

Password Keyboard – Replace SP to display a virtual keyboard; user clicks keys to fill the password field.

Face Camera – Not defined in CEN/XFS; currently implemented via browser plugins; future work needed.

Fingerprint Module – Replace SP to return a fingerprint encryption string after user selection.

Receipt Printer – Replace SP to suppress real printing and output content to an electronic document.

4. Implementation Results and Future Optimizations

4.1 Current Effect – Simulators for ID card, magnetic stripe, password keyboard, fingerprint, and receipt printer have been packaged, and a face‑camera OCX control has been developed. Major transactions in the cash‑dispenser system can now be tested automatically and are in production use.

4.2 Future Directions – Gradually support the remaining 17 peripheral types, improve test coverage, and address the limitation that simulated tests cannot reveal compatibility issues between the application and real hardware drivers. Recommendations include stricter hardware procurement specifications, thorough driver testing during hardware acceptance, and a period of manual testing before switching to automated tests.

Long‑term, a robotic arm could be introduced to perform full‑process UI automation with real peripherals, achieving end‑to‑end testing.

Index

Peripheral Name

1

Card Issuer Module

2

Password Keyboard

3

Receipt Printer

4

Cash Receipt Printer

5

Withdrawal Module

6

Deposit Module

7

Bill Dispensing Module

8

Bill Collection Module

9

Chip Card Reader

10

Contactless Reader

11

Passbook Printer

12

Magnetic Stripe Reader

13

Face Camera

14

Environment Camera

15

ID Card Module

16

Document Printer

17

Document Scanner

18

QR Code Module

19

Fingerprint Module

20

U‑Key Module

21

K‑Token Module

22

Signature Pad

23

High‑Resolution Camera

Author: Xie Bin, China Agricultural Bank R&D Center