Scenario:
In order to realise real-time value for cash deposits at remote sites, our client wished to implement end-to-end financial billing in support of the iTRAMS automated cash receiver mechanism.

realtime Overview:
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.
Conceptually, the process appears relatively straightforward -
react to incoming transactions by generating the required banking transactions.

iTRAMS Device
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:-
  • Deposit cash and notes into the device at any time.
  • Bank all or portion of deposited funds at any time
  • Select the account for the funds to be paid into


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.

 
 WebBot Workstation
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.

Highlighted in green in the accompanying conceptual diagram, the WebBot Workstation provided the required magic.
A simple Windows client running a Macro Scheduler instance allowed us to bridge the gap between the payment requests and the banking institutions.


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.processflow
  • Monitor the Incoming_Txn table for new transactions
  • Process each new transaction encountered
  • Create and update entries in the Processed_Txn table
  • Generate audit trail entries and other reports as desired.

Automation Challenges
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 !!
It was most gratifying to be able to present this working solution.

* We had an iTRAMS device setup in the boardroom and hooked up the display to the projector while demonstrating the device capabilities, cash deposits and then a payment request.

* We then switched the projector input to the laptop where we then fired up the Scheduler and watched as it was able to drive the Internet Banking platform and effect an EFT.

* We then switched the projector input back to the iTRAMS display to show the request completion.

* ... and also to hold up my mobile phone to show the payment notification SMS I had just received :)


I trust you found this article informative.
Macro Scheduler is a versatile tool for your automation arsenal !!

Robin Martin - May 2013