Blog article
See all stories »

Transformations - the hidden fly in the payment hub implementation ointment

The implementation of any new enterprise payments hub comes with multiple different challenges.  Indeed headaches abound, from changes to operational procedures, to definition of new workflows, to updating of organizational structures, to the management of distributed access to information.  But when it comes to the development and deployment of new software as part of the payment hub implementation, what activity generates the biggest headache aka, the largest fly in the ointment?  

Is it the building of new payment methods; the orchestration of workflows, the creation of routing decisions to systems, functions, or clearing mechanisms? Or, is it the creation of new user front ends and new dashboard-driven experiences?  In fact, it’s none of these.  Within a modern payment services hub each of the functions listed above are delivered as user-configurable items, driven by the flexible input of parameters into the system. These configurable functions don’t require the development and deployment of new software, and if they do, you’ve bought the wrong hub.

It will come as no surprise to anyone involved in payment systems implementations, or more importantly, in enterprise payment hub set-ups and ongoing maintenance, that integration turns out to be the biggest development headache of them all.  More specifically, it is the creation and delivery of data transformations within the integration service itself that creates the ointment in which the fly thrives.

Every time a transaction enters or leaves the hub, it needs to be transformed into the correct destination format, be that the hub itself or, a destination clearing mechanism or, an internal reporting system or, a customer engagement channel, etc.  This transformation process requires the development and deployment of software, and whilst it has never been a trivial task, it has now evolved into being the largest and most challenging aspect of both implementing and maintaining such user-configurable systems.      

The scope of this transformation development challenge is generally linked to the size of the organization involved, i.e. the number of customers, systems, the number of markets to be serviced etc. However, even the most basic form of payment hub implementation can require as many as 20 brand new system interfaces, or more precisely, source and target integrations to be built.

These range from payment source channels such as mobile, retail and corporate internet, to Host to Host file imports, to ATM and card networks, to branch and kiosk systems. Added to this list of direct customer channels, are the internal transaction systems interfaces, ranging from clean payments, to treasury, to lending, securities, trade finance, as well as internal business systems such as payroll and supplier payments. Other entities within the organization may also need to be linked into the system such as insurance, asset management, leasing, and private/wealth management groups, along with clearing networks, both local and international, high and low value, as well as remittance and billing networks. Finally, after integration of all of the above source and target systems, there are still a vast number of newly-emerging alternative payment services such as Ripple, Bitcoin, PayPal, ApplePay, Stripe, Dwolla, Mpesa, Google Wallet, etc. that have to be continually accommodated as and when they appear.   

Of course, each of these source or target destinations may not be serviced by just one message format, numerous messages may need to be exchanged, from the transaction itself, with multiple customer variations and proprietary formats, to confirmation and status messages, exception records and reports. Each service has its own formatting rules, both syntactic and semantic. Constantly changing message formats mean that new and updated payment data transformations must be continually developed and deployed throughout the lifecycle of a payment hub.  Safe to say, this process is never a one-off exercise.

Any organization may already have an ESB/Middleware infrastructure in place to lessen the connectivity and transportation burden. There may also be a defined standardized, centralized canonical model in place to somewhat ease that transportation and transformation process, but it is still a huge and ever-expanding task to get data into and out of the defined canonical model. 

Consequently, even the smallest payment hub implementation will require the development of between 100 and 150 data transformations. Whilst the average payment hub project can be anticipated to create between 350 and 500 message transformations, a large scale, multi-country, enterprise hub, can generate the need for anything up to, and above, 1000 format transformations.  

It’s not just the sheer number of transformations to be developed that is the problem, but it is also their complexity. To design, build, test, deploy, document, and maintain an individual format transformation can take anywhere between 2 and 30+ man days depending on the simplicity or complexity of the requirements.  These new pieces of functionally critical software must be deployed into the live environment, and even beyond the initial implementation program, there can be anywhere between 25 and 200+ more of these payment hub transformations to be built every year to support the ongoing needs of the business.

The result is 100s to 1000s of man days in development effort, testing, documenting, upgrading, and deploying depending on the size and ambition of the change program and your organization, and it is never ending, making those who have given the tasks due attention against those who haven’t, a key competitive differentiator.

So don’t ignore or dismiss the fly in the ointment.  The efficient development and deployment of data transformations are a critically important factor in a successful payment hub implementation. Don’t underestimate the challenge.

It is by far the biggest, continuous software development activity that you’ll need to support and so speed of development and flexibility of delivery really matter. How good is your tooling?



Comments: (4)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 08 May, 2015, 17:22Be the first to give this comment the thumbs up 0 likes

As a payments professional involved with global payment hub design and implementation, I agree that integration is a major challenge. However, I haven't come across any brand of payment hub that handles diverse payment methods like FPS, SCT and TARGET2, all in a single hub. Based on my experience, core functionality does still seem to be a major challenge.

Mick Fennell
Mick Fennell - Volante Technologies - Dubai 11 May, 2015, 20:12Be the first to give this comment the thumbs up 0 likes

That's interesting Ketharaman, as I'm aware of quite a few payment hubs that handle diverse payment methods, certainly combining RTGS, international, and local, in various jursdictions, including SCT and TARGET2. However, I grant you that Real Time clearing can mandate the need for a second 'pipe' in some organisations. On the other hand, I think that there are quite a few payment hub vendors out there who are pushing the 'one hub to rule them all' story, and I don't doubt their belief in their solution's ability to meet that challenge. In reality, whether an organisation needs one hub or a combination of systems to address the challenges faced in today's dynamic payments market, they still need to actively transform the incoming and outgoing transactions into these service pipes, and that problem is still the fly in the implementation ointment for any new payment system.   

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 12 May, 2015, 09:09Be the first to give this comment the thumbs up 0 likes


Agreed. In 2009, TowerGroup published a report titled "Waiting for the (Payments) Hub: A Play in Three Acts". Here's a tragicomic passage from this report:  

"TowerGroup believes life imitates art when it comes to payments hubs. In Samuel Beckett's play Waiting for Godot, the main characters, Estragon and Vladimir, wait expectantly, yet unsuccessfully, for a person named Godot to arrive. Although both men claim to know Godot, they admit that they would not recognize him if they saw him. Further, when discussing Godot and what he can do for the men, Vladimir states, "Oh ... nothing very definite." As the play progresses, the men discuss a variety of actions they can take to pass the time until Godot arrives. Unable to decide on a course of action, they ultimately choose to do nothing because "It's safer," so they continue to wait, presumably indefinitely."

This paragraph rang so true in 2009. Six years later, it still rings quite true!

Mick Fennell
Mick Fennell - Volante Technologies - Dubai 13 May, 2015, 07:07Be the first to give this comment the thumbs up 0 likes

I really like the analogy, and I think in some parts of the world, and in many organisations, it definitely still rings true. However, in the six years since 2009 the momentum for change has increased significantly. Driven by the customers desire for real time delivery, service transparency, and omni channel engagement, banks are having to address major challenges to remain competitive in the market. They are starting to realise that it is no longer viable to 'stay safe'. They need to standardize their processes to ensure efficiency whilst supporting flexibility & speed to manage constant change created by new XML clearing standards, new real time clearing services, alternative payment services, proliferating customer channels, regulatory mandates, customer sophistication, and increasing volumes. The day of the system tweak and little enhancements here and there are past us. The days of payment infrastrucure overhaul and payment hub implementations are here. Not everyone is doing it yet, but when one sees the major, regional players in emerging markets starting to lead the charge, which is what is happening now, then one has to say that the corner has been turned and no one can wait indefinitely anymore. Godot has arrived!   

Now hiring