Over the New Years holiday 2009, the VP Bank Group […]
Over the New Years holiday 2009, the VP Bank Group successfully switched its IT platform to the new Avaloq banking system. The migration took place on schedule and without problems, following a development phase of 18 months. Since January 5, 2009, all of the Bank’s transactions are being processed via the new platform.
The switch to the Avaloq banking system represents an important milestone in the evolution of VP Bank. It enhances the Bank’s efficiency, supports the implementation of its strategy and underscores the competitiveness of the entire VP Bank Group.
In the coming months it will now be a matter of gaining experience with the new system and, if necessary, implementing optimization measures to ensure a maximum of client orientation. The implementation of the system in Liechtenstein, Switzerland, the British Virgin Islands and Singapore has resulted in valuable know-how that will now be of great benefit in the introduction of Avaloq at VP Bank (Luxembourg) S.A. during the course of 2009.
VP Bank put the Avaloq Banking System into operation on 5 January 2009, a successful going live which concluded a comparatively brief implementation phase. Experts considered this project to be especially demanding from a technical point of view. The management of VP Bank had set four strategic IT objectives that were to be met. Today, six months after the initial introduction, the figures indicate that the system operates very successfully. This is especially true of the excellent system performance and the stability that has been achieved with low CPU usage.
VP Bank has been using the Avaloq Banking System for approximately six months. Following a relatively brief implementation phase of around one year, the bank has drawn up its initial assessment. VP Bank sought to achieve the following IT objectives with the Avaloq Banking System:
• The Avaloq Banking System must cover the entire range of private banking functionalities.
• Five separate, legally distinct group companies must be represented within the Avaloq Banking System.
• A central interface for VP Bank Group’s international bank locations must be included as independent business unit in the Avaloq Banking System.
• The Avaloq Banking System must provide a central interface to internal systems.
This project represents one of the most complex MESI-based Avaloq implementations to date. Sönke Björn Vetsch, Chief Group Information Officer of VP Bank: Even in the face of such complexity and high transaction and output volumes the system provides an outstanding stability and performance coupled with low CPU usage. According to VP Bank the following facts and figures underline this excellent performance:
• The system uses only three to a maximum of six 2-GHz CPU cores to serve around 500 end users processing 50,000 transactions on an average day.
• On 31 March, when end-of-quarter processing required the generation of additional interest and fee orders and approximately 95,000 pages of additional output (account statements and extensive asset statements of around 20 pages with many charts), processing was complete at 4 a.m. as planned, even though the date switch only occurred at midnight. The end-of-quarter processing was thus comparable to normal end-of-day (EOD) processing.
• If overnight output processing were reduced (end-of-quarter asset statements would then be generated by 8 a.m.), it would still be possible to work with half of the original 16 CPUs recommended by Avaloq, even during peak times.
• Even with approximately 450 jobs in EOD – many of which are composed of multiple tasks – the process has run completely automatically and unsupervised since 6 January, also at the end of months and quarters.
This outstanding system performance and stability along with low CPU usage has been achieved (and maintained) thanks to dedicated and consistent monitoring of the overall application as well as tuning the use of memory, CPU and IO by individual processes and jobs. We also optimised the entire EOD process (process chain, resourceoptimised parallelising of individual tasks) during the project phase and following the going live.
It became apparent that correct settings
• of certain auxiliary containers,
• of the Garbage Collection and the
• keep values for pillars and messages
were essential not only for CPU usage but also to control data growth.