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?