Introducing Euros to the Bank of Ireland retail system

The system in question

The Bookkeeping system was custom built in 1985, as an IBM Mainframe, COBOL, IMS batch system, maintained in a Panvalet Source Management System.

Apart from adding in some DB2 and Eztrieve elements, it remained technically unchanged since, although the functionality, inevitably, grew enormously. It operated as a single currency system (Sterling in UK, IR£ in Republic).

The Euro challenge

Introduce Euros (accounts and monetary transactions) in Republic only while allowing flexibility in case the U.K. joined EMU, against a backdrop of Y2K renovation of the system which dictated moving to COBOL II and replacing Panvalet with Endevor.

Design

The basic requirements:

• Any customer can lodge or withdraw funds in either Irish Pounds or in Euros
• Any customer (although businesses targeted) can maintain any account in either Irish Pounds or Euros

All basic banking functions remain in £ - including interest calculation, bank charging and bank level accumulations. Euro Accounts are identified by a new indicator on the account database while Euro transactions are identified by unique transaction codes.

The currency of an account has no bearing on the transactions it processes - both types of account (Euro or Irish) can process both types of transaction (IR£ or Euros.)

All accounts will continue to maintain an IR£ balance while Euro accounts will also have a Euro balance. On Euro accounts both balances will be maintained individually.

All IR£ monetary transactions will continue to have only one amount on them, an IR£ amount. All Euro transactions will have two amounts: the original Euro amount and the equivalent IR£ amount. 

In the case of an IR£ transaction on a Euro account, the Euro equivalent must be calculated on the spot when adjusting the Euro balance. In all other cases, the IR£ amount and/or the Euro amount will be fed to Bookkeeping by the capture/source system.

The existing transaction detail storage mechanism is unable to hold the new Euro Amount field without significant rebuilding. Euro Amount is therefore stored on a separate (already existing) DB2 table.

Statements must show all transactions in the currency of the account. Any transactions in the other currency must be shown with the original amount included for information.

Therefore, on a Euro Account, all debits, credits and balances are shown in Euros. But any transaction that originates in the IR£ has a second line of description shown, which displays the original IR£ amount of the transaction.

In addition, 'Educational' information is now output to statements -– showing Euro conversion rates and, on IR£ accounts, the Euro equivalent of the closing balance.

The need to cater for a second currency, on both account types, leads to significant changes to all customer outputs. In particular, changes to the Statementing system led to a decision to re-engineer it completely.

An interim solution was put in place for 1/1/1999 but the entire Statementing System is to be re-engineered, asap after the Euro cutover on 1/1/1999. This is currently on target for implementation in Mid-April 1999. This Re-engineering is also driven by the decision to store Euro Amount on a DB2 table.

Rounding issues

It's possible that a customer could, for example, go into a branch 5 times in one week, and on each occasion lodge a cheque for 1 Euro to the account. Assuming the account started with zeros in both the Euro and the IR£ balance, the effect would be:

Euro 1.00 IR£ equivalent £0.79
Euro 1.00 IR£ equivalent £0.79
Euro 1.00 IR£ equivalent £0.79
Euro 1.00 IR£ equivalent £0.79
Euro 1.00 IR£ equivalent £0.79
- - - - - - - - - - - - - - - -

Euro 5.00 IR£ equivalent £3.95

BUT The IR£ equivalent of 5 Euros is IR£3.94

This could lead to the complication where, for example, the Euro balance could be positive while the IR£ balance negative, leading to potential error situations such as interest being applied on an account that appeared to be in credit or, worse, in an extreme case, a cheque being bounced for insufficient funds.

A divergence elimination process is therefore essential, and it must maintain the integrity of the Euro balance field at all times.

It is also essential that all source systems sending Euro transactions must feed both the Euro amount and an IR£ equivalent.

This covers the possibility of rounding differences introduced at the point of capture, as otherwise the Bookkeeping system will not be able to guarantee arriving at the amount lodged/withdrawn by the customer.

In the above example, if Bookkeeping received only an amount of 5 Euros, it would calculate an IR£ amount of 3.94, which is not what the customer received at the capture point.

Other impacts

One basic assumption made was that, as promised by Brussels, the rate was irrevocably set - the design does not attempt to cater for a fluctuating rate. Should the rate fluctuate, it is likely the entire design would disintegrate!

A second major assumption had to be made concerning the U.K. Although it would have been better to build something that would allow seamless switch-on should there be a change of heart in the U.K., our business offices in Belfast and London were unable to define any rules.

In addition, the allocation of transaction codes in the Republic involved redesignation of a number of existing codes. Neither Britain nor Northern Ireland would agree to these codes being redesignated in their jurisdictions.

This led to a situation where, for example, code 123 could mean Euro Debit in Republic, but mean Direct Debit in the U.K. For reasons such as this, the design for Republic could not accommodate the U.K. Should Tony Blair and co. take the plunge we can only hope we get sufficient notice.

Problems faced

• No test environment
• No development environment
• No testers
• Few experienced system developers
• Process of major system testing of Bookkeeping abandoned in favour of small scale integration testing
• Y2K ongoing in background
• COBOL II and Endevor introduced
• The first EMU development – spotlight
• U.K. retaining transaction codes – double whammy on testing

Facts and figures

Phase 1 effort: 1800 mandays
Phase 2 effort: 800 mandays
Phase 3 effort: 800 mandays
Remaining effort: ? mandays

Amended Programs: 121
Recompiled Programs: 149
Amended JCLs: 497

Implementation approach

Bookkeeping changes to be in place before all others.

The business identified critical functionality, which had to be in place before 1/1/1999 if the Bank was to offer a competitive Euro service. The first EMU development project, in the Bookkeeping system, started in July 97, with targeted implementation date of Q2 1998, allowing a 6 month bedding in period while Euro changes 'slept'.

Newer, equally critical requirements that emerged during the Phase 1 development, were built and implemented between July and December 98. Less date critical requirements were deferred to asap in 1999, and a current development is aimed to implement in April 99. Not surprisingly, some more requirements have emerged since cutover and these remain to be scheduled.

Delivery mechanism

A full release of the Bookkeeping System, with full system test.

This meant two major developments amending the same system simultaneously: Y2K and EMU.

Y2K partitioned Bookkeeping into 3 lots, based on when programs ran. EMU had to change programs impacted by the design regardless of where they slotted into the Y2K schedule.

In some cases, EMU were able to take YK'd programs as a baseline. In other cases, EMU had to try to

Y2K programs, and pass them to Y2K for validation. In addition, EMU had to separately Y2K test any date amended programs.

Testing approach

The scope of the changes demanded a major system test of the Bookkeeping system. The project carried out limited integration testing with the branch front-end Enquire and Update system but all other integration testing was outside the project scope.

The overall scale of change across so many retail systems, not to mention International and other systems, was so vast; it could only be tested on a large scale basis. This was carried out in October 1998.

The lack of experienced tester resources made it difficult, as usual, to test as thoroughly as desired, and in effect the regression test was devised on a mainly manual, 'old grey heads' basis - the project has not used automated testing tools as yet.

Additional overhead was caused by the need to define testing processes and methodology - as testing of this size had not been carried out within the Bookkeeping system for a couple of years.

Major deliverables were Fagan Inspected. Program Specifications and code changes were initially QA'd. All Y2K changes were unit tested (subject to review by the Y2K program). All program changes were first unit tested, then passed on to System Test.

A testing team was assembled through using the in-house SQA function. This supplied an experienced testing leader and a team of inexperienced testers. The independence of the team was, if not assured, then at least bolstered, by its reporting to the head of the SQA in addition to the EMU project manager.

The first task facing the Test Team Leader was to define a testing process, from scratch, and then get this process agreed by the business and development teams. Meanwhile, a developer team had to set up a new test environment from scratch, by taking a full copy of the production system (databases, files, jobs etc,).

All running of system tests was carried out by the development team as the assembled testing team did not have the expertise. All marking off, however, was by the testing team.

Testing outcome

Testing revealed the usual range of errors, particularly surrounding the areas of processing Euro transaction on invalid dates, not correctly calculating Euro balances on Euro accounts, and significantly botching customer statements - these errors were all finally eliminated. Integration testing also highlighted some inter-system misunderstandings. Testing was completed in time, and sign off achieved.

Live

The Phase 1 release, in July 98, proved in itself very successful but there were a number of downstream fails where systems feeding off Bookkeeping had not made necessary changes. There were also a small number of version control problems caused by the parallel development with Y2K.

The December release was very successful.

Full switch-on was on 1/1/1999, and again the Bookkeeping system proved very stable. However, some flaws in statement design led to small number of problems. More significantly, again some other systems either misunderstood the basic design or else failed to make any changes for Euro!

By mid-January, Bank of Ireland was processing thousands of Euro transactions successfully and successfully maintaining hundreds of Euro accounts. Sign off of the Bookkeeping changes had been obtained from the Business and the Support Area.

By early March, there were no live queries or outstanding issues with what had been delivered to date.

Conclusions

EMU affects a broad range of systems - and it might not always be possible to identify impacted systems. Therefore comprehensive integration testing across systems is essential.

Parallel major developments (e.g. EMU and Y2K) are not nice!

And a final word of warning: All the effort put in to date by the Bookkeeping project alone (about 3200 mandays) deals only with the transition phase, which lasts from 1/1/1999 to 31/12/2001.

We still need to address the issue of full cutover to Euros and the elimination of IR£s. Remember, in Irish terms, 79p = 100 Euro cents - so there are more Euros than pounds. The situation will be fairly similar in the U.K.

If you enter Euroland, what are the implications of that on your databases?

Tom Coughlan