This case-study covers the proof-of-concept demonstration, with particular focus on the development of an interim automated process to facilitate the required banking transactions.
Despite ongoing negotiations with the relevant parties, permission had not yet been obtained to submit transactions directly into the banking system. Until that had been granted, this interim process had to be reliable, stable and reasonably secure. As a minimum security requirement, we then insisted that beneficiaries be controlled and defined externally to the automation process.
Highlighted in orange in the accompanying conceptual diagram, this device is an automated cash-receiver mechanism mounted atop a vault(safe) for secure storage. It provides a Cash Deposit function at customer locations country-wide, using an embedded Windows operating system for both the client interface as well as providing the required (secure) network connectivity. Once installed the customers may:-
IS iTRAMS Hosting
Transactions eminating from the remote devices are received at the host site and consolidated in the main iTRAMS transaction-log tables on an MS-SQL database.
An additional process will be developed to create a Payment Request record in a separate table. This may be via a database trigger or directly from the device (as a copy).
Although this table could be located in the main iTRAMS database, for reasons of security and separation, we proposed that a separate database be created for the purpose. The automated financial process would then access and update tables in this database only which would then be referenced by the iTRAMS devices to provide immediate user feedback on the progress of their payment request.
Considering the temporary nature of the project, to keep costs to a minimum as well as avoiding any environmental impact in terms of technical support, we proposed that the automation processes be housed externally to the server platform.
Automation Process Overview
The automated process was developed using the Macro Scheduler script and using secure ODBC connection to the remote server. Initially an IPSEC secure tunnel between the client location and the hosting center, it was later changed to an MPLS connection for production.
As can be seen in the flow diagram, the automation requirements were reasonably complex, having to cater for multiple bank portals and to anticipate various error conditions.
Due to the varying nature of current banking websites, automation of the banking process needed to be developed specifically for each bank to be accessed. Although the graphical front-ends remained largely static during the project, any change to the website needed to be detected and catered for to prevent automation failure.
In addition, the design of current banking sites is such that certain aspects do not lend themselves to automation at all. In response to hacker and phishing attacks, banking sites in particular have been redesigned to remove any URL parameter visibility and avoid keystroke access. One example of this is the menu structures, where the menu link is often dynamically presented only on mouse hover. Another example is beneficiary lists which are only populated subsequent to an asynchronous server call (AJAX).
Any automation of the front-end needed to be flexible enough to survive minor changes to screen layout in future versions – without incurring major redevelopment.
As far as possible, the inbuilt IE browser supplied in Windows was used as this can be driven directly using internal Macro Scheduler commands.
Demonstration Success !!
I trust you found this article informative.