I can imagine how you all must have felt upon learning of the comments made by Western Union’s CEO regarding how their xRapid pilot had not shown any savings over their current system. The article, published by Fortune, was a jumbled piece of journalistic fare, and certainly painted a negative picture of Western Union’s xRapid pilot and their CEO’s current frame of mind. Yet to be fair, the piece did include a counter view provided by Ripple’s Asheesh Birla who made a couple of very important points that I’d like to focus on today.

Often times, superior technologies and the solutions they provide are slow to gain adoption. There are many reasons for this, though many assume by default that it is purely a “risk” decision in terms of new technologies not being sufficiently vetted or proven. While that is a part of the slow roll to wide-spread adoption, a more basic explanation can be the lack of desire to write off capital expenditures made for their existing infrastructure. Add on the soft costs associated with employees and their specialized training, and you have the perfect recipe for delaying acquisition of revolutionary technologies.

An example of this can be found in the enterprise world of telephony services. While many may blanketly assume that being employed by default includes a work area, a computer, and a phone tied to the outside world, we often neglect what it takes behind the scenes to deliver such services. Telephony has been provided for more than a century in a surprisingly static way: a series of manually connected endpoints (phones) to a central location by way of a rat’s nest of thin copper wire. This central location itself was also connected to yet a larger centralized location or “exchange” that – you guessed it – was connected to another, or in some cases, a relay exchange that itself would connect to a national carrier’s main exchange network.

This “Hub and Spoke” design, repeated over and over across the world, is woefully inefficient. Requiring manual interconnection by physical wire, as well as the countless pieces of proprietary hardware that is wholly dedicated to a singular purpose. To run and maintain this hopelessly inefficient design takes an army of specially trained personnel. That training is both expensive and again, as proprietary as the equipment they manage. It doesn’t take long to understand that “wholesale” change in such an environment is almost an impossibility – as there is a vested interest in wringing out the very last bit of capital investment from these very expensive legacy infrastructures.

That is why, when IP-based telephony solutions emerged it took almost a decade for them to be adopted into the enterprise in significant fashion. Large corporations and SMEs found their CFOs looking at their books and realized that despite what the new solutions offered, there were financial losses that would need to be accepted if their capital investments had not fully depreciated. Further still, even if their infrastructure had been fully depreciated, what about the costs involved in training existing staff on new technologies and the actual time it takes to install? How about the numerous internal processes that were built into the legacy infrastructure – such as call recording, contact center agent call distribution and reporting, billing solutions and internal corporate development and/or processes? These costs and complications are actually the primary reason that new technology is slow to realize mass adoption – and not that the technology itself is not ready for production use.

IP Telephony was a massive evolution for the industry. Incorporating it into the enterprise massively reduced the infrastructure footprint required to deliver the same services – and so much more. Gone would be the massive refrigerator-sized cabinets that were as power-hungry as they were outrageously expensive. Gone would be the proprietary hardware devices connected by countless miles of expensive copper wires used to connect each phone. Gone would be the highly expensive leasing and support contracts from telecom vendors and the legion of internal specialized personnel required to move and support phone sets and call center software.

Gone – because IP Telephony utilized the same Ethernet cabling infrastructure employee PCs connected to. It also utilized commodity server hardware from a multitude of server providers, and often would require just a pair of those servers to provide the same, or better services. Open software solutions running on the enterprise network now had access to telephony capabilities, and developers began to produce integrations that reduced costs even more and resulted in new solutions that were vastly more efficient and economical, as well as offered more utility.
Enterprises knew what they could do with IP Telephony – but they couldn’t get budgetary approval to acquire it due to infrastructure assets lacking full depreciation.

This is where Western Union, and many other corporates find themselves today in terms of adopting the XRP Ledger and surrounding solutions the ecosystem is now developing. They see the potential. They know what they are missing by not adopting. They desperately want it before their competition pounces. Yet they have the reality of being burdened by large capital investment in proprietary infrastructures that cannot be integrated easily – if at all – into an XRPL-driven solution. Western Union is hopelessly restricted by its use of purpose-built kiosks and software integrations into the businesses those kiosks reside in. Western Union has spent decades building their proprietary infrastructure, and though it is a technological marvel – it is nonetheless the best solution possible for a technological era that is now in its last waning moments of existence.

This is why it is an exciting time my friends, and we must keep our fingers on the pulse of the greater movement at hand. While we all hinge on the big names in the industry signing on as partners and for xRapid pilots, the real disruptors in this space might just be the names none of us have heard of. Where Western Union dominates the current remittance landscape – providing best in class (but very expensive) solutions for the financial tech era imminently expiring – startups and more nimble players in this space are free of the legacy infrastructures that prohibit quick adoption of XRP. Unless Western Union is willing to ignore its legacy capital expenditures and depreciation schedules, as well as upend its countless proprietary integrations with business and partners – it is extremely vulnerable to an aggressive unknown entity stepping in and claiming a substantial share of the market.

Which I surmise, is the very reason Western Union’s CEO Hikmet Ersek used the platform of the Fortune interview to make some calculated statements in derogatory fashion towards the xRapid pilot, while trumpeting their internal 10 digit codes used in money transfer as a superior solution and akin to digital currency.

It is my belief, that Ersek knows his current financial burden and is angling for a better deal from Ripple for software and integration efforts, and probably a whole lot of XRP at a discounted rate. His comments were nothing more than an attempt to gain bargaining power as he must have felt the publicity of Western Union’s pilot meant more to Ripple than the cost of the software, services, and XRP for a Western Union integration Ripple would charge to them. It’s a gamble by Ersek, a very public one, and one that defies the enthusiastic reports by other corporate leaders currently performing xRapid pilots.

So what do you think?

Did Ersek overplay WU’s importance to Ripple? Does Ripple need WU as much as WU needs Ripple and XRP? Did Ripple dismiss WU and offer MoneyGram a better deal instead? Is there a sleeper about to make this whole discussion about WU irrelevant?

Time will tell – and it might not take too much more time to tell …

(Edited: The Reverend incorrectly used financial and accounting terminology when attempting to relay his opinion. For this he apologizes, profusely.)

Until next time my flock –

The Reverend Ripple
@Reverend_Ripple