Listed on Euronext and the New York Stock Exchange, France Telecom Group is a global telecommunications company with 159 million customers, two thirds of which come under the Orange brand. France Telecom has 191,000 employees and reported consolidated sales of €51.7 billion at the end of 2006. This month we talk to Raffi Basmadjian, Deputy Treasurer, about the impact of SEPA and the evolving technological landscape.

What are your responsibilities?

I am in charge of all the new treasury tools and processes, from conception to implementation. Basically, once a process is up and running, I work on its improvement, or on another process aiming at completing or replacing the existing ones. It is a neverending story.

One such new process was the adoption of a new tax status for treasury. All the group treasuries of MNCs are looking for the best tax treatment. Often that triggers the relocation of central treasuries – from Switzerland to Ireland, from Ireland to Belgium, from Belgium to the Netherlands. Because a lot of MNCs were relocating their treasuries to Brussels, for instance, the French state decided to create a new tax status, called the Centrale de Trésorerie. This is pretty much the same thing as the coordination centres in Belgium.

We took this up at the beginning of 2003. We wrote a new treasury agreement and had it signed by the subsidiaries that were working with us as an in house bank. It was a lot of work with our legal people and tax people – and of course with the French tax authorities. Each time we sign a new treasury agreement with a new subsidiary we have three original copies – one for us, one for the subsidiary, and a copy that we send to the French tax authorities.

Another project I have been working on is setting up a group treasury website. We decided to go further than just making available group policies and end of month rates and are providing subsidiaries with a set of tools and treasury applications, such as Reuters Cash Flow. By June, we’re going to make an electronic banking system available to everybody. We will promote the use of the group treasury tools instead of stand-alone tools by the subsidiaries – the idea is to have everyone working on the same database with the same set of tools, streamlining the transmission of information because everything will be there and available at the push of a button. We already have 60 entities in it; in the second half of this year we will expand abroad – in the UK, Switzerland, Spain, Belgium – and slowly integrate all of our subsidiaries in the platform. As they will be using our systems remotely, they will keep a certain level of autonomy.

How are treasury operations organised at France Telecom?

Treasury operations are fairly centralised: funding is centralised, inter-company payments (netting operations) are centralised, hedging (FX and interest rates) is centralised, and so on. We are now focused on improving the accuracy of the data we work on. Indeed, France Telecom is a 400 subsidiaries group, with treasury related operations in 94 countries. At this scale we need to be very efficient in the way we use the available information.

What have you done to prepare for SEPA?

We have been collecting information from various sources (eg newspapers, financial publications, conferences, discussions with banks and consultants) and each time we found reliable (ie ‘official’) information to work on we adapted our systems.

Thus, we have been collecting all BIC and IBAN details for years, mainly for the cross border transfers, quite a while before the EPC decided to make this information mandatory in cross border payments. We also have invested in a SWIFTNet infrastructure in order to be ready to use international channels and standards before all the current domestic formats and protocols become obsolete.

Internally, we have communicated with all departments that may be subject to changes due to SEPA such as procurement (to have them collecting all BIC and IBAN from our suppliers), HR (to populate their database with the same type of information for payroll), accounting (to make sure payment files could be presented with BIC and IBAN) and so on.

What challenges still remain?

Our main problem is that the level of communication from the payment institutions (and therefore of awareness across the market) is very low. We are still missing a clear and official pan-European roadmap to SEPA.

In order to take advantage of SEPA in a payment world with fewer boundaries, we will need to adopt a different structure, at least at the scale of the Eurozone. This is in itself very challenging. Basically, the scope of SEPA is to make domestic what was international before. Today, I can carry out an operation in Paris in exactly the same way as I would in Brittany, for instance. Tomorrow, I should also be able to do operations in Greece as smoothly as I do in Paris. That’s the bottom line.

So now say that we just adapt our systems to SEPA – we adopt the SEPA standards, the SEPA formats and the SEPA protocols – but we don’t do anything to the organisation. Tomorrow we’re going to have an organisation which is still following the divisions between the countries, while we could just operate in all the countries from one location, one bank account and so on. SEPA is an enabler and it is up to the corporate and the entities in the SEPA zone to take advantage of it. If we just look at this as additional work to do without improving our operations, we will not make any savings. Of course, this is linked to group culture, to the group’s ability to adapt to this type of change.

For the time being we are just preparing the systems. We have been part of the SWIFTNet initiative from the beginning, and in terms of corporate-to-bank communication we will be ready very soon, by June or July. In fact this is broader than the SEPA borders because when you are on SWIFT you can communicate with European banks, Asian banks, banks in America and so on. We are currently using MA-CUGs and we are hoping to move over to SCORE before the summer. It will make my life easier. We have four MA-CUGs at the moment. When we focus on cash management in the second half of 2007, I will communicate with as many banks as possible through SCORE. Currently, at least for France, I need 20 banks. I don’t know if all of them will be part of SCORE or not. Hopefully they will, but everything takes time.

What technological developments do you expect to affect treasurers in the next few years?

The old X.25 networks are becoming obsolete. That will accelerate the use of IP (Internet) based products in the next few years. Five years ago, SWIFT was in the X.25 network, and they migrated to IP – that was the SWIFTNet project. However, locally at least, the generic protocols are still based on X.25. Of course, the small businesses that have a one bank approach have been using the internet for years. When you only have one bank you can use the bank’s proprietary system, but large multinationals have to work with various banks. We can’t use all the proprietary systems of all the banks we are working with, due to the size of the company and the number of banks. So we need generic systems, and at least in France the generic systems are based on X.25.

We know that this will change in the future, but if we do not have any use for X.25 in the future then all the protocols defined today won’t be usable. So we need something instead of the standards we have today. Currently, nothing is there. That’s one of the reasons we decided to be part of the SWIFTNet initiative. Without any information on what could be the new French standards, or European standards, we decided to make the move to SWIFT. At least we have the pipes, we have the protocols. Now we have to work on the formats.

SWIFT has two systems – FIN, which is for the old MT format, and FileAct, in which you can use any type of format. So the idea is to have SWIFT connectivity to the banks through FileAct, then use the local standards while waiting for new European ones, ie the ISO 20022 XML. Then we will need to communicate with the banks, to make sure that they are going to use those 20022 standards as standards. The existing MT formats are supposed to be standard, but in fact if you want to implement an MT101 you see that the banks are not using the standards in exactly the same way.

How do you see the issue of security in payments developing?

I will speak about France, but I believe the logic is the same in other countries.

Most countries have designed their standards at the national level, and that’s true for security too, at least in France. In France they created a secure protocol for bank-to-corporate communication, which is called ETEBAC 5. This is a standard security protocol used by all the banks. All the corporates could subscribe to this type of security. I’m not saying that all the corporates are doing so, but all the big ones are. This security issue is a matter of personal signatures, making sure that the person making the order is authorised to do so. This is what the current standard, ETEBAC 5, does in France.

In the SEPA world, we know that the formats will be standardised, the protocols for accessing the banks will probably be standardised, but security is not part of the discussion, because someone decided that it’s in the competitive space. For me this is an issue. When I have to prove my identity I use my passport. This passport is delivered by the state – a recognised authority. When someone wants to check my identity at an airport he can do that quite easily, because all the passports are the same and they all come from same source – so it’s easy to identify whether my passport is real or fake.

When you say that security in corporate-to-bank operations is a matter of competition, you mean that various certification authorities will be able to provide you with an ID. And I really don’t believe in that. It’s technically feasible, but when you think about it, the problem is that I will have always a bank to tell me that this certification authority is not a good one, you should take the other one, and so on. Also, depending on the certification authority, the protocol used to identify yourself could be different. It’s going to be cumbersome to explain to all the signatories in my system that with this bank you’re going to need to identify yourself this way, with this other one you have to identify yourself another way, and so on. I don’t see the need to have various certification authorities. To me it will bring us more problems than solutions.

What projects are you working on in the next 12 months?

I will finish putting in place all the treasury management applications for FT Group. I hope that by June everything will be modernised: the latest version of our treasury and cash management tool, a payment and e-banking system compatible with SWIFT. For the second half of 2007, I will be focused on the implementation of our systems in various big subsidiaries of the group and on setting up a payment factory.