Message man

Banque Libano-Fransaise deploys an intelligent middleware and messaging layer to extend its customer channels and beef up its financial services.

  • E-Mail
By  Matthew Southwell Published  July 2, 2002

I|~||~||~|Like the majority of the region’s leading financial institutions, Banque Libano-Francaise is heavily investing in its retail banking operations. It plans to both extend its customer channels and beef up its financial services. To this end, the bank is improving its ATM backbone and developing an Internet channel, as well as enhancing offerings such as foreign exchange.

However, unlike most of its counterparts, Banque Libano-Francaise is not facilitating this change by replacing its existing infrastructure or its core banking applications. Instead, it is deploying an intelligent middleware and messaging layer from IBM.

Ghassam Sawaya, IT manager at Banque Libano-Francaise, explains the primary motivation for this was the bank’s desire to retain the database engines that drive its transactions. Created when the 25 strong IT team built the core banking system, the engines comprise standardised groups of transactions for processes, such as accounting, non-accounting and special modules.

“To rebuild our transaction engines in a new system would have been like reinventing the wheel and we were not willing to do this,” comments Sawaya.

Although the bank could have developed its extended delivery channels and applications within its proprietary core banking system, such a move would have created an integration and management nightmare at the back end, something the IT team was keen to avoid.

“We could have directly implemented each retail banking channel inside our ERP since it’s an in-house development. But I did not want go for such a solution because this would create application spaghetti at the back end,” says Sawaya.

Banque Libano-Francaise examined a number of middleware products, including Tibco and BEA, before opting for IBM’s WebSphere. Initially, MQSeries and MQSeries Integrator Broker were not part of the WebSphere bundle. However, Sawaya still opted for Big Blue as the vendor promised that the messaging components — which form a key part of the deployment — would be integrated in future.

“When I first started looking at MQSeries, it was not part of the WebSphere package — it was sold in bits and pieces. However, IBM said ‘take everything, develop your applications and you’ll be a showcase for us.’ As a result, we opted for them,” explains Sawaya.

“Also, we wanted to move to a standard middleware that had a large market share so any software we bought had at least a 70% chance of integrating immediately,” he adds.
Once the decision to opt for IBM had been made, Sawaya had to get his IT team up to speed with MQSeries and the WebSphere platform. This was achieved by sending staff for training at IBM’s Electronic Transaction Processing (ETP) Centre in Montpellier, France.

The team completed an intensive three weeks of knowledge transfer with the IBM team that had completed the original proposal and architecture development for Banque Libano-Francaise.

||**||II|~||~||~|“If you don’t get the correct training then you might be doing things wrong. You have to get trained to understand the concept correctly. Also, once you’ve acquired the skills, you can deploy and develop it pretty quickly,” notes Sawaya.

The deployment has seen Banque Libano-Francaise separate the application and messaging layer, essentially leaving the core banking system as an application island that is connected by MQSeries to everything else.

“The clear cut difference between the message and the application is integral as it allows us to retain the Oracle-based core banking system. It also gives us a clean, neat interface that integrates to the distribution channels, while talking directly to the back end. The message remains within MQSeries and the processing is done in the procedures of the database, so it makes use of the engines that I have built,” says Sawaya.

Oracle Procedure Gateway ensures that MQSeries messages can talk to the Oracle database, which allows the bank to continue using PL/SQL within the Oracle database to guide information towards the delivery channels. “PL/SQL carries out the validation within the database and it is triggered whenever a transaction comes in through MQSeries,” explains Sawaya.

All of Banque Libano-Francaise’s message queuing is completed in real-time, rather than in batches. Intelligent routing within MQSeries ensures that each message reaches its intended target. This is key because the majority of the bank’s transactions need to be completed rapidly. For example, a request triggered by an ATM transaction has to be responded to in realtime so the customer receives their money immediately.

Aside from ensuring speedy functions, the messaging queue is loaded with business logic to ensure it is fully validated. The first decision comes when the message identifies the transaction type. Once this is done, an association is made between the request and its corresponding back end process. The data within the request is then transferred from its original fields to the fields in the back end by embedded ESQL. A decision is then made on the validity of the data and the request before it is processed and sent back to the presentation layer.

For example, a request to withdraw money from an ATM requires validation of the PIN number and whether or not the customer has sufficient funds in their account. If either is incorrect the middleware layer will prevent the request triggering the fund release transaction at the Oracle back end.

The ability to reuse MQSeries messages at the middleware layer will be vital as Banque Libano-Francaise extends its service offerings. Rather than having to start from scratch every time the bank wants to add a new transaction capability, it just has to reconfigure MQSeries Integrator Broker.

“We leverage our original investment because we do not have to write any more programmes. The whole idea is to minimise how much code we have to rewrite,” says Sawaya.

The bank is already doing this as it extends its foreign exchange capabilities with an out of the box solution from BMI. Rather than develop a number of application program interfaces (APIs) to connect the application, the foreign exchange department’s standalone database and the core banking system, Banque Libano-Francaise’s IT team has linked the three with MQSeries Integrator Broker.

||**||III|~||~||~|“By using MQSeries Integrator Broker, the BMI application and the core banking apps at the back end can use the foreign exchange database concurrently, which increases processing speed,” explains the IT manager.

At the same time as deploying the BMI app, Banque Libano-Francaise is planning an online initiative. By the beginning of next year, Sawaya hopes to have a basic e-banking offering in place, through which customers can check their balance, order chequebooks, send messages to the bank and complete account transfers.

The IT manager confesses that the bank could be seen as being behind the times when it comes to Internet services. However, he believes that although many banks already have e-banking offerings, they do not have the integration necessary for them to be a long term success.

“I know we are late with Internet banking, but many other banks have just deployed standalone applications and do not have the correct infrastructure. We have, so we know that we will be able to run 24x7 without any problems,” says Sawaya.

The Internet delivery channel will sit on top of the IBM middleware layer that is already in place. Therefore, all the IT team has to do is develop the presentation layer. Sawaya explains that this is being done using WebSphere’s Model-View-Controller (MVC) and Java.

“What we are doing right now is developing a front end using J2EE. The front end will run on WebSphere and talk to the middle tier, which will send the information to the back end and return it to the presentation layer again,” he comments.

“It is essentially the same transaction that I developed for the ATM switch, the only difference is the presentation layer,” adds Sawaya.

This ability to replicate the basic MQSeries messaging formats, irrelevant of which channel is involved, will help Banque Libano-Francaise accelerate the deployment of other delivery channels in the future, such as mobile.

“Later on we might want to use the development to do pervasive computing where we can offer services to PDAs and mobiles. We will be able to do this easily because we already have the transcoders on WebSphere,” he says.

Whichever channel Banque Libano-Francaise receives information from, it is standardised within MQSeries Integrator Broker. This is essential as it ensures that the core banking application can receive and process transactional data.

“All of the different channels generate different outputs. However, MQSeries Integration Broker takes this output, leverages it into one format that my application understands and then kicks off the transaction related to this request. If we did not demand a standardised message we would have to have engines for each different transaction and this would make the back end too complex,” explains Sawaya.

“Achieving this standardisation without using MQSeries Integrator Broker would have been too time consuming,” he adds.

In addition, because each delivery channel uses the same messaging format, the transactions remain the same. Sawaya believes that this standardisation will simplify customers’ interactions with Banque Libano-Francaise. “The customer will have a single view of the bank, which brings consistency and improved service,” he says.||**||

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code