An Internet Banking Framework with Perl


Carlos de la Guardia

Javier Rodríguez

Aldea Internet 


 Aldea Internet Banking Framework is a Perl-based Web application that allows financial institutions to provide to its customers a wide spectrum of online banking services, including home banking, enterprise banking and virtual points of presence. Architecturally, the framework integrates seamlessly to the bank’s legacy systems through a Communications Module, and allows the integration of improved customer services by encapsulating most of the business logic in a separate Operations Module. As an application, its ultimate goal is to complement -and eventually replace- the expensive online banking in-house developments based on closed or proprietary technologies.

This paper describes the architecture and inner workings of Aldea Internet Banking Framework and the finer details of its implementation for one of the largest banks in México: Banco del Atlántico.

The project

Our customer, Banco del Atlántico, had an application, developed in-house, which allowed its corporate clients to process transactions and consult a number of reports generated on the fly, like balances. This DOS-based application connected via modem to a terminal server located at the bank and from there talked to a mainframe application which actually carried out the desired operations.

The problems with this approach were many: low security, modem and phone line needed for every client, high installation costs and times (because every new version had to be installed all over again), incompatibilities with different versions of the operating system, maintenance nightmares with the code and unhappy clients.

The bank decided to use Internet technologies to solve these problems and at the same time begin the transition from their old, inefficient systems to more modern developments. They also came up with a bold idea for minimizing the cost and resources required for opening new bank offices.

The political situation in the bank at that time made necessary the division of the project in three phases. The first one was the creation of a front end for their current systems that substituted the current client program for a web browser and some server side applications and integrated security measures. The second one included the modifications of this front end necessary for dealing with point of sale equipment, so that it could be used as a mini-bank inside video rental stores equipped with just a computer, modem, bar code scanner and printer. The third phase was the gradual substitution of the old mainframe applications for newer systems developed from scratch to fit the new paradigm.

This paper deals with the first two phases of the project, in which Perl played a major role.

The challenges

From the beginning, the project presented a lot of difficulties. The time frame given to us was rather small (only eight weeks from conception to implementation) and the application was meant to be in production by the fall of 1997. Many bank officials considered the project a wild goose chase. The mainframe applications with which had to interface were not very well documented. And finally, the people responsible for them were seldom if ever at hand.

In México, most banks have their own in-house development teams, and there are no standards for applications programming or file formats. Also, since the banks in México were nationalized in the 80’s and re-privatized some years later, there have been a lot of changes in systems management and policies, together with a high personnel rotation.

All this has created a situation in the banks where a consultant is faced with extremely old systems which run a variety of applications coded in different languages and very poorly documented (no source code available in many cases). Banco del Atlántico was a good example of this situation.

Another problem that we faced was this: the existing application used a session-oriented message exchange protocol, so that clients did all their work in a single connection. Of course, the web protocol is a stateless one, so we needed a way to maintain state between web connections that at the same time tricked the mainframe application into thinking that everything was happening in a single session.

In short, we were presented with the following challenge: create a middleware capable of communicating with a session-oriented COBOL application running in a UNISYS mainframe, which then could interface with a stateless web server to present the old information in a new, attractive format in a web browser.

The approach

We decided early on to use a modular approach for the construction of this project. The idea was to encapsulate tasks like communication with legacy systems and business logic into separate modules. This would hide the implementation details from the main application and each other. This way, if changes were made to some part of the system in the future (say, the COBOL application gets updated or a new machine is added), only the pertinent module would need to be altered.

To solve the ‘stateless protocol’ problem, we decided to redirect all web connections to persistent processes that kept an open session on the mainframe for each client.

System requirements



One of the main goals of the project was to have the ability to implement and integrate new business functions easily. The key to this was the modular approach. Our design was made in a way that allowed new procedures to be effortlessly inserted into their place as if they always had been part of the original design.


Since the plans of the bank were to eventually offer their Internet banking services not just to corporate clients but to would be home bankers everywhere in the country, we had to plan for huge numbers of users from the very beginning. We decided to use a process manager that would route petitions to the first available server process, so that new servers could be added easily as the number of customers required it. Initially only one server would be used.


We’re talking about a bank with a direct connection to the Net here. This mere tough sends shivers down the spine of most people on the financial market. But we counted on our experience in Internet programming and on a certain HP product named "Virtual Vault".

Export restrictions were much of a concern, too. Even though the US Department of Commerce allows the export of domestic-level encrypting servers out of the US for use by (some) foreign financial institutions, the browsers available at the time outside the US were unable to interact with a domestic server product using full-strength cryptography. This restriction proved to be unacceptable to the customer.

In order to solve this issue, a third-party product called SeguriProxy was integrated to provide full-strength encryption of the channel trough a proprietary protocol.

This security solution introduced another problem for us, since the Virtual Vault OS is really picky about what things can run in its protected area. We solved this by using a small C program residing in the Virtual Vault’s sandbox as a bridge between the web server and the real web application.

A network diagram showing the role of the Virtual Vault is shown in Figure 1.

Architectural overview

Figure 2 shows the different components involved in the application.

Why Perl?

First of all, we believe in Perl. We know what it can do and have been promoting its use for important projects since we started working in this field. Also, we like Perl and would rather work with it that with other languages whenever possible.

But most important, the particular conditions of this problem made Perl the perfect solution. Which other language would allow to turn in a successful application in a short time frame and with less than optimal working conditions? Which other language offers such an open repository of proven tools capable of greatly reducing testing and development cycles?

Advantages of using Perl


Implementing persistency: the application core

Since the core of the developed applications belong either to the bank or to Aldea Internet, which is our company, we are not at liberty to give away all the code from our work. However, Aldea has allowed us to freely distribute the code from our process manager, which in many ways was the heart of our solution. This module is available electronically at .

Anyway, the majority of the modules developed for this project are too specific for our client and not of real use for the general Perl community.

We feel that the process manager could be a really useful tool for those who want to interface with session based legacy systems using stateless protocols like HTTP. Due to the time limits set for this project the tool is far from completed and could maybe be used more as a model than as a finished application.

Some ideas we came up with for this program during development are:

We have found in our experience that the first two problems mentioned are fairly common in the financial sector when dealing with legacy applications and their integration to new technologies like the web.


This project was very successful for us and proved to many unbelievers that Perl can really offer solutions to complex problems in the real world of financial institutions. Not only did we save time and money using Perl, but also developed a strong and scalable solution with minimal recoding because of Perl’s strength joined with its unmatched properties as a ‘glue’ language.


 Carlos de la Guardia is Director of Systems Development at Aldea Internet. He has five years experience in developing Internet applications. He can be reached at Aldea Internet, Daniel Delgadillo #5, Tlalnepantla, Estado de México, México. CP 54050. or

 Javier Rodríguez is Research and Development Manager at Aldea Internet. He received a BS in electrical engineering from ITESM Campus Estado de México and has been working on Internet Application Development for the last six years. He can be reached at Aldea Internet, at or


An electronic version of this document is available at .