• Ajit Kanagasundram was confident that mainframe is capable of supporting global cards processing as well as banking
• Citibank's Global Go to Common project is considered the largest banking technology failure in history
• He believes that the challenge today is developing new applications for mobile and the net

Here is the transcript:

Emmanuel Daniel (ED):  I am very pleased today to speak with Ajit Kanagasundram. And those of you who have been in the banking technology in the last 20 to 30 years will remember Ajit for having built a global processing capability for Citibank. He was with Citibank between the years 1983 and 2004, retiring as the managing director of cards and banking applications.

Ajit Kangasundram (AK):   Applications, yes.

ED:  And having had the privilege of building and selling internally, the cards processing capability on a global basis to, how many countries around the world?

AK: At the maximum it was 38 countries: Asia, Middle East, Europe, and Latin America.

ED: Now walk us through a little bit of how technology has changed, and what has changed about technology in the time that you’ve been with Citibank, since 1983, and what hasn’t changed in technology today? You are basically a mainframe man. I think you believe in the mainframe’s capability to support a global cards processing capability.

AK: And banking.

ED: And banking. What about the mainframe is not replicated by the cloud or an external service system?

AK: Okay, let me start. In the late ‘80s, no one had tested large scale multi-geography processing on the mainframe. They knew that they could handle single large volumes in North America, but would it work across geographies? So a few things happened, in the early ‘90s mainframe MIPS became much cheaper, when IBM moved from large water-cooled processes to air cool seamless processes.

So, the same platform was available at a much lower cost. Now IBM has a monopoly on MVS, so the pricing has always been high, but they are also sensitive to the market. So, by lowering the cost, they expanded the market. The second thing that happened is that with the introduction of fiber optic submarine cables, international communication bandwidth went up by a factor of 20, and the cost also came down.

So, it was possible to have centralised processing for multiple geographies. Now coupled with that, in 1989, Citibank decided to set up a regional processing hub in Southeast Asia, only to do what were essentially the ASEAN countries, Singapore, Thailand, Malaysia, and Indonesia. Now, I was appointed to head that. I was formerly in charge of regional banking. And it was such a success that North Asia, which had originally planned to have their own processing centre in Hong Kong, doing Hong Kong, Taiwan and Korea, decided to join the Southeast Asia, or what we call the Regional Card Centre.

Once that was done in the mid ‘90s, Japan also decided to come in. Japan, at that time, was being processed by Sumitomo Bank, but high costs, about $30.00 a card. And very poor service in terms of responsiveness, but extremely high quality, the sub second response, their system had never been down, etc. So the first question the Bank of Japan asked is can the Singapore Regional Card Centre replicate this?

So the Bank of Japan sent a team down and looked at our set-up, looked at our past record and they said, okay. The head of Citibank Japan, Yashiro-san, was a very senior a Japanese banker, and then took the decision to move out of Sumitomo Bank. It was a difficult decision because in Japan, you don’t break business relations or keiretsu easily, and we moved it here. It was a difficult move because we had to customise the system for the Japanese language, and there are very special processes that they had, but we managed to do it in 18 months.

So by 1996, we had all of Asia, including Japan and Australia, being processed out of Singapore. Now, you must remember, all during this time, costs were coming down. When we first started, it was about $7.00 per card per year, data centre, and applications costs. But because of higher volumes and lower processing costs, lower telecommunications costs; this had now come down to about $4.00. Then, in the late ‘90s, there was a move to try and process Europe and Latin America on the U.S. bank card system.

That failed because the U.S. bank card system was built for high volumes, not to do multiple geographies at medium volumes. So in 1999, I was told to move and extend your system to Europe, Western Europe, and Latin America, which I did over the next three years. Latin America was processed from the data centre in Singapore. Europe, we did the application development work, but we processed out of Germany, because the EU privacy laws don’t allow you to send data outside the EU, but we controlled everything from here.

So at the height, there were 38 businesses being processed by one application, cost had meanwhile come down to $3.00 per card, per annum. And this is still the only international system that Citibank has. I don’t want to mention other banks. Other banks using a similar platform have tried to do four countries for $200 million. We did all these countries for $50 million.

The main reason for success is really that we had a team in Singapore that was experiencing cards at a highly competent mainframe technology. You can't replicate that. We had an extension in India and China, but the key designers and testers were in Singapore.

ED: So was there a period where you had more countries subscribing to your processing and then it started to fall?

AK: No. No one who ever came on our system ever wanted to get out. The problem was Citibank got into trouble with the CDL fiasco in New York. And they had to sell their businesses in Western Europe and Latin America, keeping only Mexico.

ED: Right.

AK:  So it was a business decision not to deal with the technology.

ED: The technology and the infrastructure. Just two related questions to what you’ve built, was it something that could have been hive off and run off as a standalone third party processing, was there a potential to run it –

AK: I was asked more than once, whether I would be willing to work for the Singapore banks. I opposed it. There was a very good reason for this. However good you are at what you are doing, there is a finite amount you can do in any release, which is a three to four month period. Now within Citibank, the condition, if Hong Kong wanted to launch a card brand in Taiwan, a very easy business decision, which shows more profits?

But if you are also processing for DBS and OCBC, how do you arbitrate between banks? The second reason is intellectual property, whatever was new innovation for Citi, one business, under one business, we gladly gave it, but how do you prevent this kind of move between banks? Well, they would guard their intellectual property. So for these reasons I opposed it.

Now, our reason for success is that we didn't have to worry about intellectual property. We didn't have to worry about prioritisation. These are very easy decisions under one bank.

ED: And how has the technology itself evolved? You are a very strong proponent of the MVS core banking platform, but today we find that many banks find it equally comfortable moving into an open server platform, and then some have even started moving into cloud.

AK: Yeah, and I encourage that. The main thing is to remember what the mainframe does is process transactions at high value, maintain the bank ledgers. Now, what is the point of moving that on to another platform when it works well? As I have told you earlier, what they should do is put a layer around, wrap this mainframe, only do minimum changes, and interface with the APIs. All of your internet, your customer facing applications, your mobile, should be on service. You don’t want to do that on the mainframe, but the mainframe will maintain the books of the bank.

ED: Yes. There was a time when we went from transaction systems; there was a preference that moved from mainframe to UNIX, to open platforms, what –

AK: For smaller volumes, yes, but the big volumes, still the major banks in North America, Europe, Asia, are on the mainframe. I'll give you an example, about seven or eight years ago, Korea decided to move their card processing platforms to UNIX. Everything worked well, they reduced their costs, but at peak periods they lost transactions and couldn’t recreate it. Now this is a major problem if you're running a financial system, so they moved back to the mainframe.

ED: Right. But at the same time, when you think about the things that you want to be able to do, APIs for example, and open –

AK: Yeah, do that on servers. I'm not saying the mainframe does everything, but what it does, it does well, so leave it alone.

ED: Yes, but then you're giving access to external users, external partners, at the same time the interaction is becoming more and more virtual, so it's not a transaction itself, but the fact that it's happening on the net for example.

AK: Yeah, so the net, you can have an API that interfaces with the net and with the mainframe. The main question about the mainframe that people ask, the main question is cost of ownership. Actually, there are two, the cost of ownership and the difficulty of getting highly trained staff to maintain it. Let me take the cost of ownership first, the cost of transferring it is quite high.

As we discussed earlier, Citibank had a project called Global Go to Common, where they tried to make all the instances of the mainframe system in Europe, Latin America, and North America the same. They started it in 2010, the budget was a mind blowing $1.4 billion. And in 2015 it was canceled, because it proved to be too expensive. I was in the forefront of developing applications for the mainframe, but this is not an indefinite thing. Most of the mainframe development work has been done, enjoy the benefits of that and leave it alone.

ED:  And in building your system, as well as protecting your turf, in terms of your choice of technology, your choice of architecture and so on, who were your supporters within the institution, and how was the institution itself evolving over time? It wasn’t like it was always technology; it had to be other priorities as well. So who were your major counterparty, and also your subordinates, who worked with you?

AK: We were very fortunate, our chairman, John Reed, was an engineer, who placed a lot of emphasis on technology. And the Asia Pacific head, Rana Talwar, also founded technology a lot. So really from the management point of view, there was no pushback. Were there proponents of other platforms, yes, Europe wanted at one time the DECK platform, but DECK went under. UNIX was always doubted, but it could never actually handle the high volumes.

At one time we had the smaller businesses in Asia on IBM midrange machines, but they couldn’t handle the Hong Kong and Singapore volumes. So there were no major threats to the mainframe.

ED: And just about the time when you're leaving the bank, the bank took a position to consolidate all these systems, and you're given it a few nuances, which is Europe, in some ways these are different from South Asia and so on. How were the nuances carried into any iteration change in the cost system, in the new era of after you left for example? 

AK:  Well, they have maintained it. They have tried to do the common for all countries, and spent $1.4 billion and then canceled it. Now they’ve gone back to what I pioneered, separate from North Asia, South Asia, and Europe. It's not infinite. You have about six instances around the world, and you transfer best practices across them.

ED:  This attempt at unifying the whole infrastructure, regardless of the fact that some of the areas that it covers have different price structures from others, so you’ve got China, you have the Middle East, you’ve got India, you’ve got Southeast Asia, and so on, so how did Citibank prioritise its restructuring, or it's –

AK: They didn't. There were about 3,000 people working on the project, and they're trying to do it all at the same time, which is a failure.

ED:  And how much did that failure cost them?

AK: $1.4 billion, the largest banking technology failure in history.

ED: And what do you think they should have done?

AK:  They should have carried on with what I did, have a release every four months for each region, transfer best practices, and tolerate minor differences.

ED:  Who were your most important supporters when you were building the infrastructure?

AK:  No, question, Rana Talwar. He funded it. In fact, when I first started, in Citibank there is a process called the major expenditure proposal. And I was struggling with that, and he said, “Look, your job is to build the best infrastructure, the best technical team. I will look after expenses.” So I literally started with a blank check, and that carried on quite a lot.

ED: And what was involved in selling the proposition to your various countries, what are the kinds of questions that came up, and how did you –

AK:  You see when we first started; the passion was each country to do its own thing. But when we demonstrated, for cards we had to do it centrally, because we wanted to launch five countries simultaneously, but the idea was that after two or three years we would look to be processing in country, but it was such a success that we never looked back.

ED:  Now, Citi is an interesting organisation, where it has a home country, which is the U.S., especially the east coast of the U.S., and it's got an international ecosystem, which arguably is based out of Singapore, or other –

AK: Singapore mainly.

ED: Okay. How do you reconcile the two, and what about the U.S. system was sophisticated, complicated, therefore required additional input, and what was available in –

AK: Okay, let me talk about the retail bank, which I know about. The U.S. system is a high volume mass market system. They have 60 million cards, but the average spend is quite low with very few features. In Asia, we have an up market segment, much more features, multicurrency, so there is very little commonality. In fact, one study found 17% commonality between the U.S. and Asia.

ED: Right.

AK:  So, there was never ever any push when we started to adopt the U.S. system.

ED:  And what about the U.S. –

AK:  They are very good at high volume processing.

ED:  But was there temptation for the U.S. to buy the system that you, or rather to pay you to develop what they needed?

AK: It was the other way around. The early stage of this it was why you can't use our system, but that was all shot by down by me, by the business managers, because as I said you don’t have all these features, which we need.

ED: Right.

AK: So fortunately that never happened.

ED:  In today’s world, where you have a lot of applications that need to be developed independently, and then integrated in order to communicate, pass messages across, what are some of the technological challenges you would imagine someone in your position would have today?

AK: You need to be very conscious of your data structure. As long as your data definitions are standard, you can have applications in the cloud. You can have applications on the mainframe. You can have applications on standalone service talking to each other. So you need a very strong functionality to maintain data structures and interfaces. The challenge today, quite frankly is to develop new applications for mobile and the net.

The cycle when I started for a new card production, maybe six months, today it is in weeks, so people have to be much more responsive. It's actually interesting; a lot of fintech applications, companies are now looking at insourcing what they outsource. For example, they say developments are far faster if your application people and the business people are talking to each other every day in the same premises, because you don’t go through elaborate system requirements, coding, and testing.

You do prototyping, rapid prototyping. Yeah, this is what I want, go, or, just change the screen, change that. So the cycles are becoming much faster and it's very challenging.

 ED: And how would it be working as a CIO today or a CTO today, relative to when you last were responsible for this?

AK:  Well, as I said, the rate of change is faster. Today you need to be master of multiple technologies, where as in my time, if you were good with the mainframe that covered most of it, so that was it.

ED: And today there is no more sophistication, no more complexity, no more –

AK: Much more. Much more I would say today, but it's in compartments. You see, banking is a journey. We built the foundation. I'm not saying that's all that ever needed to be done, what I'm saying is the new guy should build on that foundation, not try and reinvent the wheel, but go beyond that.

ED: And what are the skill sets that are coming on stream now? I mean, I'm sure that there's not many CICS or C-I-C-S.

AK: That's a problem. As I said, you would check the facts. All the big banks in Europe, America, Asia are on the mainframe, but no one for the last 15 years in America or Europe goes to learn and wants to learn this. So this has migrated by default to India and the Philippines, but even there, the young people don’t want to learn this, so it's going to be problem.

ED: Ajit, you are not just a builder of systems for your own bank, but also you're an observer of how competition is evolving, who do you think will be the next Citibank building across border, regional, or international, or global infrastructure?

AK: Very interesting. When we started in the ‘80s and ‘90s, a big North American bank, who could spend on technology, had an inherent advantage over the local banks. That has gone. Today a DBS, or an OCBC, or a country I know well, Turkey, their banks are as good as anything in Western Europe, because they have access to the same technology, the same consultants. So the advantage of the big traditional countries like the U.S. has gone away.

And I think smaller banks are much more nimble. They can make decisions faster. They can change faster. They have less baggage to worry about.

ED: Well, what about building and scaling quickly?

AK: Yes, you can scale, right?

ED:  And what about processes, where banks, the institutions that want to have a much more highly unified structure, where they treat all transactions the same, and therefore benefit from the cost per transaction?

AK: Well, this has been an argument all the time. Actually, the cost to process by is going down, so why unify something which is going down in cost. Tolerate a bit of diversity. It's better to innovate in new production services, rather than to constantly re-engineer your back end.

ED: And so leave the back end alone?

AK: Alone, unless you need to change it.

ED: And that's advice that you would give regardless of the size of the institution?

AK: Especially, regardless of the size. I just told you Citibank spent $1.4 billion and failed, and they put their best brains on the job.

ED:  And why do you think they would have failed –

AK: Because the job is inherently difficult.

ED: I see. But the variations on the open markets are –

AK: That's part of it. Partly, then you have to start arbitrating between requirements of different countries. If for example, you had Europe and Latin America on a different platform, if Brazil wanted something quickly, you could do it, but if you wanted them on the same platform, you have to go through every country in Europe: do you want this? Do you want this? Do you want this? So the whole requirements process becomes longer, the code becomes more complex.

And then testing, remember if everybody is on the same platform, if Brazil changes something, everything country in Europe has to test it to see whether it affects them. So you don’t want that.

ED: Right. You’ve had a fascinating history, who were your, not just mentors, but champions, who understood what you saw, and helped you to build it?

AK:  As I said, I was very fortunate. The Citibank senior management, people like George Reed and Rana Talwar, and later Bob Willumstad, they supported me a lot. They saw the vision. Within banking technologists, I’d admired the people who built the U.S. bank card system, because they built it for very high volumes, very high service levels, so I have some internal people. Citibank, one of our problems is we tend to be arrogant. We thought we were the best.

ED:  Yeah. Well, it's been a fascinating life history. And we look forward to reading your deep intake, in terms of your experiences that you’ve had. Can a Citibank, having launched a monolithic project, $1.6 billion, to create that processing capability, can they step away from it do you think?

AK: It has. It has. It has taken that right down and moved off, they failed. I mean, they could have used that money to buy PayPal and really changed the equation; instead they put it to re-engineering the back end, which is the wrong thing to do.

ED: Ajit, thank you so much for spending time with me today.

AK: Thank you.

ED: The article that you have written gives an even deeper perspective, and I would encourage our readers to go into our website and read your wealth of experience in building a global processing capability, and couching for the fact that it continues to be relevant today.

AK:  Thank you.