With the extensive growth in the financial industry especially in United States and Europe in the early 90’s, an immediate need was felt for an industry wide platform to standardize the development of the financial systems. Microsoft at that time was the first one to realize this necessity and founded “Banking Solutions Vendor Council” in 1991 which comprises of leading vendors of Information technology of the financial Industry. Based on the windows platform using “Windows Open service Architecture” the very first version of the Financial Systems development Framework was introduced as “Extension for Financial Services” or WOSA/XFS. The very first version of XFS was released in 1995 followed by XFS 2.0 in 1997. We are using XFS 3.10 at the moment in 2008.
XFS was a revolution and a major success in the financial industry which leads to its adoption by CEN (European committee for standardization) as an international standard in 1998 and was named as CEN/XFS.
Wikipedia defines CEN/XFS as “CEN/XFS or XFS provides client-server architecture for financial applications on the Microsoft Windows platform, especially peripheral devices such as EFTPOS terminals and ATMs which are unique to the financial industry”.
I as a developer of the XFS will define it in simpler manner as “An SP (Service provider) independent windows based set of APIs for communication with peripheral devices like EFTPOS and ATMs”.
You can make your system XFS compliant by following the following three conditions:
- The Service providers should make their device drivers compliant with the “XFS Manager” as distributed by Microsoft.
- Must be Win32 based.
- Should be compatible with the published XFS API definition.
The key element of the XFS is the definition of set of APIs and a corresponding set of SPIs providing services to Windows based applications. XFS provides the set of APIs to the application developers which they can use without getting worried about the service providers; for example the Printers of the ATMs are provided by multiple vendors in the market, by implementing an XFS based application the developer should not worry about the make and model of the printer if the printer SP is compatible with the XFS Manager and XFS API, the same application will work without changing a single line of code. As far as I know all the peripheral device providers of ATMs and EFTPOS now are compatible with the XFS Manager and hence supports the XFS APIs.
One of the most powerful things provided by CEN/XFS is Form based printing from the peripheral devices like journal, receipt and document printers. Form is a simple specially formatted text file which is called within the XFS based application using the XFS APIs. The main advantage of using Form based printing is the ease of editing the printing data without recompiling your code but the developer should have to be very careful while editing a Form because a single wrong byte will crash the whole system and cause the machine to restart. There are many tools in the market to generate an XFS Form.
All the Financial standards like “Aptra Advance NDC” by NCR and “DTC” by Diebold are XFS compatible hence are vendor independent. XFS is the reason which made AANDC work on Diebold ATM machines without using any Emulator. NCR realizes the importance of XFS quite late in 2004 where they started developing their first XFS based vendor independent software AANDC 3.0. Before the release of 3.0 XFS was introduced in the AANDC 2.6 but at that time some devices were supporting ADI (Active Device interface) which was the reason of not completely moving to XFS.
We as the providers of the ATM extension application like Biometric authentication over ATMs, Non EMV Chip card transactions on ATMs, Cash and Cheque deposit enhancements on ATMs and integration of CRM with ATMs have a lot of applications of XFS. For me our perfect implementation of XFS was a system developed for Oman Arab Bank in 2007 to support DUET standard Chip cards over the ATM. I used XFS APIs to communicate with the Card ICC where we were reading and writing the card holder data on the chip and the XFS forms for printing Receipts and journal.
The implementation went extremely successful because no code was changed for different devices of the ATMs and I was really very relaxed except in the very end of the implementation just before the GO LIVE activity the Bank requested the journal printing module which was not even written, that was the point where I really felt the flexibility of XFS API because I only changed the logical name of the receipt printing module to journal printer and the journal printing started working.
For the bank it was an amazing thing, a completely new module of journal printing developed and tested properly within a day just before the GO LIVE activity (not to mention how thankful they were), but for me it was only a function call with journal printer logical name provided instead of receipt printerJ.