'It Feels Like 2000 Again': Swift CEO on the Fintech Boom

The annual Sibos conference is considered one of the leading opportunities for bankers, vendors and technophiles from around the world to gather and talk about the future of the industry.

The event, sponsored by the Society for Worldwide Interbank Financial Telecommunication, or Swift, draws as many as 7,000 attendees. This year's conference is next week in Singapore.

In advance of the conference, Gottfried Leibbrandt, chief executive of the Belgium-based international cooperative, was in New York last week to meet with bankers to talk about Swift's compliance services and to brief reporters on its strategy.

American Banker sat down with Leibbrandt for a broad conversation. He talked about the ways Swift, best known for its bank messaging network, is looking to stay relevant to its bank members; the potential and limitations of blockchain technology; and his views on the startups looking to disrupt the industry. The following is an edited transcript of that conversation.

At Sibos last year, Swift made a big push for the KYC registry service. Can you give us an update on that initiative?

LEIBBRANDT:We now have over 1,000 banks. It's aimed at correspondent banking. It's "know your correspondent bank" rather than "know your customer," which distinguishes our service from what others like Markit or [the Depository Trust and Clearing Corp.'s] Clarient are doing. We're really focusing on correspondent banks, of which we have I think in total about 8,000 on the [Swift messaging] network. Of those we have signed up 1,000 for the service which is actually quite a steep take-up for the small group we have, including almost all of the larger banks.

So that one, as far as we're concerned, is full-on go. Later this week we are meeting with senior representatives of the big banks in New York taking up where we are with the compliance services.

We also offer sanctions testing: essentially we take 100,000 standardized messages, we put them through the filters the banks have themselves and then, based on positives and negatives, we can help them tweak the filters and then point out which things they miss. That one has done really well. It's aimed at the bigger banks [Swift has 30 of them using it]. And then we have sanctions screening for the smaller banks that don't want to have an in-house filter. There, we are close to 300 customers.

Do you see the registry taking a broader role than just correspondent banks later on?

To be honest, we'll see. It wouldn't be the first priority. First of all we're going to have quite some work to get from 1,000 to 10,000. There's a lot of work and it's also about the quality of the data filling the repository. In terms of expansion of the service, we would look more at deepening the services we do for correspondent banking rather than broadening it to others. And it's very hard to see where we are five years from now once this is fully rolled out. And it will probably also depend on how the other [KYC services] are doing. If the others are doing a good job of signing up the rest – corporates, funds etc. – then what's the need for ours?

We've taken the same approach with sanctions screening. Four or five years ago there was a discussion: Should there be a joint industry utility for the larger banks to pool all of their screening? In the end there wasn't enough consensus on that. We said at the time, rather than focus on building this big global utility let's do something practical and let's focus on the smaller banks that are having problems. That's worked out well. And I think we've taken the same approach to know-your-customer. Rather than trying to boil the ocean, let us focus on that part of the world which we know well, correspondent banks, where we can provide real value-add. Implement that and we'll see where that takes us.

The pitch for a registry is similar for a correspondent bank as it would be for a customer – minimizing duplicative paperwork, standardization?

There are two aspects to it. One is indeed the standardization of the information. You only have to submit it once. Which is a bit different for a bank: it includes the bank charter, who is the overseer, the license and all of that. There are specific data that are relevant for banks that aren't relevant for corporates, trust funds and the others that Clarient and Markit service.

The second part of the service is to provide the ability to a bank to show the one who's checking them what their traffic patterns are like, which we can do because that traffic happens on the Swift network. So we allow them to share with their correspondent who their counterparty is. And that allows you to see not just who's your correspondent but who's your correspondent doing business with, which is more than just the paperwork. It's more insight into the existing relationships.

Presumably that would inform whether you want to do business with a correspondent?

Or whether you'd want to do business with [a correspondent on] this type of business but not that type.

There's been some skepticism about banks' willingness to collaborate on this. Due diligence is a lot of work, so, for example, if a global bank knows the one bank in a developing country that has good compliance, why would it want to share that information with its competitors?

I think banks have moved from seeing this as a source of competitive advantage to literally a cost burden that no longer distinguishes you and there is a need for joint solutions. It's a little similar to the discussion on corporate access [to the Swift network] 15 years ago. Banks thought that corporate access and corporate connectivity was a source of relative advantage. I think they are slowly seeing that is not [something] on which you want to compete, which is why the whole debate on whether corporates should be allowed to connect to Swift directly has gone from something that was very difficult to something that is more or less taken for granted. And I think we've seen the same in compliance.

I have to say that did change over the last four or five years. We've gone from "no, we want to do this ourselves" to "this has become such a burden. We do have to share costs here." Unless the banks can have joint utilities and share costs there's no way we're going to cope with the onslaught of this regulation.

To be clear, they're looking for joint utilities, not just us. You see Clarient, you see others. I wouldn't claim that we're the only solution in town, absolutely not. They're looking at everyone that can provide shared costs.

The U.S. is now moving toward real-time payments. How long do you think it will take to get there?

Depends what you mean by real-time payments. We have real-time payments galore, it's called card payments. If you limit it to real-time transfers, we are seeing it in some other countries. But if I were to compare Europe and the U.S., I wouldn't be able to say one is moving faster than the other. We've seen a few, England has moved with Faster Payments. Singapore has moved. Australia, where we're now building it [Swift has a contract to build a real-time domestic payments system there].

This is not going to be built overnight, especially not in a complicated environment like the U.S. I appreciate it's more complicated than a small country. Australia had the advantage of a limited number of banks, maybe 15 banks that are participating which is equal to the UK. It's easier to do than in the U.S. where you have 6,000 banks, multiple clearing infrastructures etc.

What role will the ISO 20022 standard play in this process?

The ISO standard is no more than a formatting convention at the end of the day. You can do real time with ISO or without ISO. Those two are not necessarily linked.

Don't you think it would help?

What we are seeing is that wherever there isn't a standard, we see people choosing 20022. We've seen that with Target2 for securities in Europe, we even see in the U.S. in a [market infrastructure] context with corporate actions with the DTCC. So I would assume that for real-time payments, where there is nothing you would choose 20022. But I wouldn't claim that 20022 would greatly facilitate the introduction of real-time payments. At the end of the day you're going to have to build an infrastructure no matter which standards you use. …If you want to convert to a new common standard then 20022 is a logical choice.

There's talk of China and Russia trying to build alternatives to Swift. Do you see this happening?

What I do see happening is people building their own national systems. Just like the U.S. has its own national systems and the Chinese have their own CNAPS. To build a truly multinational system, across the world, that will be harder. Then you have chicken and egg problems to overcome. But maybe, at some point if they decide they want to do it, then it can be done.

At Sibos last year you indicated that Swift was starting to look at the blockchain, the distributed-database technology behind Bitcoin. What have you learned since then and what is your thinking now?

It's a very interesting technology to watch. Everyone is now having their own sort of proof of concepts on it. What I find interesting are the applications where the blockchain is used to register the ownership of more general assets than just Bitcoin. You could store the ownership of certain securities contracts. You could store the ownership of certain funds in there. If there are certain types of securities where the clearing and settlement is really inefficient then I think that could provide a good solution for that.

As always, I would expect it to move first where there is nothing yet and where there is a real problem rather than replacing infrastructures that function today. We are looking at it from two angles: One, if people are to adopt the blockchain for transfers of assets what role could Swift play in that? If they run in a private blockchain setting, could we run the identity management? Could we provide the telecommunications and messaging that is needed to make it work?

The other one, and you'll find more and more banks look at it, is what could it do to replace your internal database technology? That one is still a little bit further away. That will really depend on what the big technology providers are going to do with it – the Oracles, the IBMs, everybody seems to be eagerly awaiting what their technology is.

Do you have a view on the merits of public blockchains versus private blockchains?

For most of the purposes in financial institutions, people are looking at private blockchains, partly because it solves the issue of mining, which is a cost burden but also slows things down. In a [public] blockchain setting, it takes 10 minutes before the block is finally vetted and it takes six blocks before the transaction can be considered final. So you're talking one hour before you have finality of a transaction. Plus, it is the burden of the computation and the average throughput is on the order of 10 transactions per second or something like that. For the stock market you'd need transactions per second to be closer to a 1,000 instead of 10 and the only way you can do that is in a private setting where you can have much faster clearing of the blocks. You also don't need the mining because you're dealing among people who know each other and you don't have to rely on the proof of work to check the validity.

In that scenario, what value does the blockchain itself bring then?

It provides a more distributed environment. And here I'm repeating what many of the startups would tell you in much more glowing terms, but the advantage of the blockchain is it would be available 24/7. The other argument is that because it is open-source software, it is much easier to integrate your systems. The third argument is its resiliency. It is much harder to corrupt a distributed database.

I don't want to sound like a snake oil salesman here. There are things that blockchain doesn't do very well. All sorts of information about the transaction – you can store the ownership, but the typical information about the transaction, like who is the ultimate beneficiary, what is it for, what invoices does it pertain to – that is not handled well by the blockchain. Partly because it is public for everybody, so unless you encrypt it, it is verifiable forever to anyone who has a copy of that blockchain. You'd probably still need a separate flow of information. The other is how interoperable it is for existing situations. It would be a great solution if you were to design it from scratch, but you don't start from scratch, you start from existing infrastructures.

I wouldn't want to be the one who says the whole world moves to blockchain in a bang. It may not be the ultimate solution for many of the existing systems. At the same time, it is a very intriguing technology and we'll have a look at it.

What do you think of Ripple?

They are evolving. If you really dig down to the way they operate and their value proposition, I think they are searching. I've got to watch myself. Half of me says it is a solution looking for a problem. A big part of what they do is retail [foreign exchange] – brokers can bid on FX transactions. Is that a problem to be solved? There is a well-functioning FX market. I'm not sure if that is the core of the problem. But Ripple is certainly one to watch and we're in constant discussion with them. It is certainly not something I would want to discard. The same goes for a number of others that I think are interesting innovations.

Fintech, even more than a year ago, is all the rage. What do you make of all of this, what is driving it and how long can it last?

I'm a natural skeptic. I lived through the dot-com boom in 2000. And to some extent, it does feel a little like 2000 again, doesn't it? There is unlimited venture capital pouring into it, the sky is the limit and everyone with a business plan and five Powerpoint [slides] with the word "fintech" in there can get funding.

In the first Internet wave, we had lots of talks about banks being dinosaurs. Banks were going to be extinct. We had hundreds of pure plays who were going to replace banks with pure-play telephone banks, Internet banks or e-traders. The banks have proven that they were more agile than people thought. If you compare a bank today to a bank 15 years ago, they are a completely different animal. If you look at what they have pulled off technology-wise, it is pretty impressive. Especially when you combine that with all the regulatory burdens we've put on them. None of the pure plays have survived except maybe two of them – PayPal and ING Direct [which is now owned by Capital One in the U.S.]. I can't think of many others that have worked, but the banks have absorbed the technology and adapted.

Part of me says the challenge is to pull that off again. Peer-to-peer lending: why wouldn't banks be able to incorporate that technology, add value to it and use it a way to add value to their customers? At the same time, history may not repeat itself. There may not be technologies that can totally disrupt banks. But I would still put a lot of my money on banks.

It doesn't happen by itself though. It was a huge effort. They are also going to have to rely on infrastructure. That is where we come in. Part of what they have done well is to have the infrastructures evolve with them. That's not just us, that's the stock exchanges, the Clearing House, Visa and MasterCard. They face that all over again, which is why real-time payments is so interesting. It is another opportunity to build around existing infrastructures or build new ones to deal with these challenges.

You have to be careful. I think in 2000, we embarked on a few ventures that we may not have done in hindsight. Had it not been the go-go years, we maybe would have been more careful. But you've got to strike the right balance.

One difference between the dot-com era and today is the advent of cloud technology and the demands for immediate action because of our devices.

But cloud technology is an opportunity for banks. It allows them to – in a much more agile way – come out with these new services as well. Rather than be tied to their legacy, they can do quick development and host it in the cloud and get up and running. Same for us, we are offering some our new solutions in a cloud way, like sanctions screening, from the perspective of the customer, is a cloud service. Many of these new technologies are just as much of an opportunity as they are a threat.

There is an inherent tension between data privacy rules and anti-money laundering and know-your-customer regulations. The U.S. government's Terrorist Finance Tracking Program accessing the Swift transaction database was one of the most salient signs of this when it was revealed in 2006. Can the tension ever be resolved?

In a broader context, there are more examples of banks being caught between conflicting legislations. We saw that with the Swiss banks that got caught between the U.S. tax demands and the privacy concerns of their regulator. There are many examples of banks being caught between conflicting regulations and legislations. How does it get resolved? Pragmatically, on a case-by-case basis.

A couple of years ago, Innotribe – the Swift division that promotes innovation in financial services – was kicking around a very interesting concept whereby banks would act as custodians of consumers' personal data, and give them greater control over how that data is shared. Where does that stand?

At the end of the day, we look at it and it provided a useful catalyst for conversations about identity management. But we couldn't get enough banks around the table for that one. I do think it was meant more to stimulate the debate.

Indeed, it seems that identity is going to be a major issue soon and what is to be determined is the role that banks play in that.

This concept is being used implicitly by the Googles and Facebooks of the world. "You give us your data in exchange for free goodies." That's the implicit contract. You get free Gmail, why is it free? Nothing is free. You get marketed all sorts of services. You get the banks saying, "We get this big data thing – but Google and Facebook get away with murder and we are not even allowed to use our bank customer data for marketing purposes." It is an interesting debate to have. And banks do know a whole lot more about their customers, especially in this era of compliance and KYC, but what are they allowed to do with that and how can they monetize that?

How do you leverage the size of your network for opportunity in the future in serving the banks and playing a role in the financial ecosystem of tomorrow?

It is twofold. Banks have to adapt like everybody. And I think one of their strengths is their infrastructures. Apple Pay is a good example. A lot of what is used with Apple Pay is a reuse of the card rails. It is a smart way of using the assets at your disposal. Same goes for real-time payments – why not use existing infrastructures and leverage that to come up with a solution? You should start with what you have and so things like Swift and other networks are things that the banks have and that would be a logical starting point.

If you apply it to us, it is the same thing. We have a community of 10,000 banks that use the same standard and are on our network and that allows us to bolt on new services on top of that. Use your incumbency to market new services and that gives you advantage over someone who started from scratch. But that also goes back to the core – you have to continue to do what you do well. The upstarts have the advantage of being more agile. They can take more risks. They don't have to worry about risking about what they already do. We have to make sure that anything we do doesn't jeopardize the reliability of our existing services. About 80% of what we do should be making sure that we do what we do well. We would not being doing our owners a service if we slacked on the existing role that we play.