EMU: The IT Implications

April 30, 1998

The adoption of a single European currency is a logicalextension of the single European market and has for decades been the dream ofmany who believe in the benefits of the European Union. It is undoubtedly themost significant step to be taken by Member States, since the Treaty was enteredinto.


The real push towards acceleration of EMU came under the Maastricht Treaty.This envisages the introduction of the single European currency for those membercountries who have attained the ‘convergence criteria’. The timetable forthe first wave of EMU has been set as follows:

1 January 1999 :

  • Effectively the fixing of exchange rates only.
  • The ‘Euro’ becomes the official currency of the participating states. The ECU disappears. The Euro is sub-divided into 100 cents.
  • Old national currencies continue, but they are redesignated as ‘denominations’ of the Euro.
  • No Euro notes or coins are yet in circulation.
  • Exchange rates between participating states are fixed against each other irrevocably.
  • The private sector may trade in the Euro on a ‘no compulsion, no prohibition basis’.

January – July 2002

  • Euro notes and coins introduced.

July 2002 (latest)

  • Domestic notes and coins withdrawn.
  • Euro replaces domestic currency in participating states for all purposes: electronic, paper and cash.

Note that countries joining in the ‘second’ or later waves are unlikelyto have as generous a transitional period.

Who will be affected?

Virtually everyone will be affected, whether in or out of single Europeancurrency. The extent to which people are affected depends on two types ofconsiderations: market sector and geography.

Clearly, EMU is an issue which is only relevant to monetary and financialtransactions. Thus, entities whose IT systems will be affected significantlyinclude banks, the financial services industry and multinationals. Those whoseIT systems will be affected to some extent include retailers, manufacturers andbusiness advisers. Entities least likely to be affected would include hospitalsand schools. Put simply, a currency conversion software programme is right inthe firing line; a programme monitoring a brain scanner will be completelyunaffected.

The second criterion for how relevant EMU will be is the geographicallocation of the entity and other entities with which it transacts. If oneimagines EMU as the planet Saturn, the central core contains those businessesbased in participating EU countries : their IT systems will need significantadjustment. In the next ‘ring’ are those businesses which are within the EUbut which will either be excluded or have chosen not to participate in the firstphase, eg Britain and Denmark. The impact of the first wave of EMU willobviously therefore be more limited in those countries but, to the extent thatthose businesses have trading links with participating countries, the issue mustbe addressed to some degree. The next ‘ring’ are those non-EU businesseswhich trade with the EU, eg American companies: again the fact of EMU will alsoneed to be taken into account in assessing the needs of such companies. Finallynon-EU countries which never trade with the EU are in ‘outerspace’ and cansafely ignore the issue!

As a pointer, IBM estimate that 80% of their application packages will beaffected by the need for EMU adjustment, in some way.

Why and How will IT Systems be Affected?

Taking a very practical British-centred view, and assuming EMU does commenceon 1 January 1999, many seem to be taking the view that minimal changes will berequired since one can simply treat the Euro as another foreign currency, andBritish businesses are well established to deal with foreign currencies.

Consider, however, the financial and monetary functions which are carried outby software – one immediately thinks of banking transactions, currencyconversion and the management of financial instruments and investments. Butthere is also the management of accounts systems, issuing and tracking ofinvoices, electronic tills, compilation of price lists, calculation of tax andnational insurance, administration of payroll and pension and generation ofsales reports. It is true that until the Euro replaces sterling in this country,it will remain a ‘foreign currency’. However, during the transitionalperiod, a country such as Germany will have two currencies in effect, the Euroand the Deutschmark. Any financial transaction with a German business duringthat period could therefore involve either of those currencies. Software isneeded to convert the Deutschmarks into the Euro equivalent and vice versa.

It is this which distinguishes the EMU issue from the Year 2000 issue. Thelatter is essentially a technical problem. EMU is a functionality problem.

The following is a very selective list of other functionality problemspresented by EMU.

  • Many packages geared to specific market sectors (eg credit checks) rely on the analysis of historical data. As French francs, Deutschmarks and guilders cease and are replaced by Euros, how will such data analysis be possible? Will all the old figures have to be converted to Euros and will that produce the same result?
  • What is to happen with packages which involve the automatic conversion of currencies as between participating Member States, which will then each move to the Euro? An acute example of this is a ‘swap’ transaction between say French francs and Deutschmarks. Software packages which deal in the differentials between interest rates within EU countries will also be affected by the fact that interest rates in participating countries will be fixed across the board by the Euro Central Bank.
  • There are national differences over such matters as bank holidays and over what periods interest rates are calculated. For example, the USA calculates annual interest on a 360-day cycle, whereas in the UK a 365-day cycle is used.
  • The currencies of Italy, Spain and Portugal have not hitherto been expressed in decimals.
  • As regards pricing, the new currency may call for a complete re-evaluation of companies’ target pricing. This could lead to the repositioning and redesign of products. For example on a pound/Euro exchange rate of 1/1.512, a £2.99 product translates as 3.76 Euros. Will the new psychological price point be 3.49 or 3.99 Euros? If the experience of decimalisation is anything to go by, prices will almost certainly creep up.
  • The Commission recommends that during the transitional period prices should be indicated in both Euros and the domestic currency. Thus label printers and till receipts will all need amending to cope with this dual price display. Cap Gemini I has recently stated that retailers face at least a 1% impact on their bottom line from the first year of EMU implementation.
  • A recent Commission Regulation lays down detailed rules for ‘rounding’ of figures in the context of currency conversion. These rules are mandatory and software programs will therefore need to be configured to comply with them.
  • There are numerous issues in relation to hardware. There is some debate as to whether computer keyboards will need to be replaced so that they include the new ‘E’ symbol. Tills will need to be able to take both types of currency as will coin or note operated machines. Note counters and forgery detection systems will also need to be changed.

Legal Issues

I do not pretend to be an expert in banking law and there are clearly amultitude of legal and regulatory issues surrounding EMU. I am confining myselfhere to IT law issues.

Existing Contracts

In many respects the analysis here is similar to that which should beundertaken in relation to assessing Year 2000 compliance. Existing contractsshould be reviewed to see whether they contain any express reference to EMUcompliance. It may well be that it was always expected that a particularsoftware package should be able to cope with the Euro, in which case failure todo so should entitle the user to a fairly straightforward claim for breach ofcontract.

The situation becomes less favourable from the user’s point of view if thecontract is silent on the issue. The user would be looking to see whether itwould have been an implied term of the contract at the time it was entered intothat the package would be EMU compliant. This will be a question of fact as atthe date of entering into the contract. If the contract was entered into morethan say two years ago, it will be open to the supplier to argue that it couldnot reasonably have been expected that the software should have been EMUcompliant if it did not say so on the face of the contract. The law both understatute (Sale of Goods Act 1979, as amended) and common law (where there is no‘goods’ transaction – St Albans v ICL [1996] 4 All ER 481) willimply, in the absence of other provision, that the goods must be of satisfactoryquality and reasonably fit for any agreed purpose for which both parties knewthey were to be put, for a reasonable duration. With a package dealing withhedging transactions in European currencies supplied during the last year or so,it would I think be reasonable to imply a term that it should take account ofEMU. For software for less obviously relevant purposes, it may be harder to makeany such inference.

Still on the subject of existing contracts, all those who operate in the areaof recommending, maintaining or managing software, eg consultants, maintenancehouses and facilities managers, should very carefully review obligations underexisting contracts to ensure that software packages meet ‘all therequirements’ of the client’s business or can otherwise ‘function fullyand uninterruptably’ beyond a certain date (eg payroll). It may be that thesystems in question simply cannot do this in a Euro world without significantalteration. Thus it may be appropriate to serve notice of termination, which mayor may not be a trigger to renegotiate the contract.

Finally, where a user is keen to upgrade or amend its system, it may wellneed access to the source code. Often this is held under the terms of an escrowagreement, but if the software owner is unco-operative the emergence of the Eurois unlikely to fall within the ‘triggering events’ which enable the user tohave access to this source code. Note also that in other situations, where thesoftware has been created to the order of a user, it may be thought that all therights in that software belong to that user. In the absence of a writtenassignment, however, copyright remains vested in the original programmers.

On the subject of existing agreements, although this is not directly relevantto IT systems, there had until last year been considerable concern as to theeffect the appearance of the Euro would have on existing contracts. CommissionRegulation (EC) 1103/97 states that the replacement of national currencies bythe Euro does not:

  • alter any term of a legal instrument;
  • discharge or excuse performance under such an instrument;
  • give any party a unilateral right to alter or terminate the instrument.

‘Instrument’ here includes contracts and statutory provisions. Thus aparty cannot seize upon the appearance of the Euro as a pretext for evading itsresponsibilities under the contract, unless provision has been made otherwise.US commentators have questioned the effect of this Regulation for businesses incountries outside the EU. In derivatives, such as swaps or hedgingtransactions, the abolition of the relevant currency or reference to an interestrate tied to an abolished foreign currency could lead to a claim that thecontract has become ‘impossible’ or has been ‘frustrated’. The non-EUparty may therefore be able to walk away from its obligation.

New Contracts

It should be obvious by now that EMU functionality, like Year 2000compliance, is one of the issues which must be addressed explicitly in thenegotiation of any new IT contract. The response of the proposed supplier of thesoftware to either of these questions will give a fairly good indication as tohow reliable it is. The less wholeheartedly positive the response, the more warya potential purchaser should be.

In terms of wording in contracts, my view is that a warranty such as ‘TheLicensor warrants that the software is capable of handling transactionsinvolving the Euro’, whilst it may provide some comfort, is so vague as to bevirtually useless. Far preferable is to agree a fully worked out functional orperformance specification and then have the supplier warrant that the softwarewill in all respects conform with such specification. Suitable acceptancetesting procedures, which give enough time to ascertain that all aspects of theprogram which need to be ‘Euro compliant’ are compliant, also need toenshrined in the contract.

Practical Steps

The EMU issue is more complicated in functional terms than the Year 2000problem but perhaps less sinister. There are unlikely to be unseen bugs orproblems with legacy systems in the way that there is with Year 2000.

(a) It is strongly suggested that in any organisation at least two seniorexecutives are appointed to oversee the EMU compliance project: an executive whounderstands the monetary and financial aspects of the business and one whounderstands the IT side of the business. With the best will in the world it isvery rare to find in-depth knowledge of both areas in one person.

(b) The financial officer should list and describe all the processes whichwould be effected by EMU in functional terms. It is also important to bring inlegal support at this early stage, to ensure that the systems to be designedmeet all relevant legal and regulatory requirements.

(c) The IT officer should at the same time list all software systems used inthe company which involve financial processing.

(d) This knowledge should then be pooled and the project team should work outwhich systems need to be:

  • replaced entirely
  • amended only
  • left alone.

(e) Year 2000 planning should ideally run alongside this, so that decisionson the replacement or modification of systems can be done most efficiently. Adecision as to whether or not to replace the system entirely is made easier ifthe system in question also happens to be riddled with millennium bugs!

(f) The team should then establish priorities in terms of what typesof systems need to be replaced immediately (such that the business cannotsurvive without them), what needs attention as soon as possible and what can bedealt with in due course.

( g ) The compliance project should then be implemented using a range of:

  • ready-made packages
  • customised versions of existing packages
  • totally new software which needs to be developed.

Positive Aspects of this Process

This is an opportunity to resolve two IT problems at once – Y2K and EMU – andtherefore represents a more efficient use of resources. It also represents anopportunity to review and upgrade IT systems generally; if significantinvestment is having to be expended to tackle these two problems, then a generaloverhaul might as well be carried out at this stage.

It is important to contact customers and business partners to ascertain whattheir plans and timetables are in relation to EMU. Your own project timetablemay be significantly affected if key customers are moving at a different‘speed’. It could provide a significant PR and competitive advantage toaddress these issues pro-actively.

Negative aspects

The process is likely to be expensive. Barclays Bank has estimated it needsto spend £250 million to ensure that its systems are EMU compliant. It has beenestimated that the total cost to British banks of this project is £1,800million. The British retail consortium has suggested that just to change alltill systems will cost the British retail industry £1.5 billion. It may not bemuch comfort to learn that the European Commission has made a formalrecommendation that these costs may not be passed onto customers (eg the cost ofconverting a bank account from one currency into Euros).

Fixing these problems will be time-consuming and complicated: if yourbusiness is likely to be significantly affected by EMU after 1 January 1999,work needs to commence immediately. It is striking that the deadline here isless than a year away, nearer than the Year 2000, and yet very few Britishbusinesses are taking any steps to deal with EMU.

It does not take a genius to realise that there is going to be a scarcity ofcompetent programmers to do all the work required.

Will it Happen?

One of the greatest problems is uncertainty. Will EMU actually happen on 1January 1999? Will Britain join ‘after the next Parliament’ or at all? Isthe determination of certain continental politicians to make EMU happen comewhat may going to mean that the project will be rushed and badly managed? Surelycalm discussion is needed about what is probably the most important economicdecision Europe will take in many decades.

However my conclusion is that it is not adequate simply to hope that EMU will‘go away’. It almost certainly will happen even if not on 1 January 1999.One must assume that EMU is here to stay, and take steps accordingly