The term ‘Payment Services Hub’ (PSH) has become the latest and greatest buzz word in the payments industry, and promises a new and innovative alternative to the traditional ‘payment engine’. This is because payment engine projects have the reputation of
being for the larger bank, ridiculously expensive, difficult to implement and even harder to prove a success, it’s therefore a difficult proposition in today’s environment. Richard Davies blog ‘What is a payment services hub?’
https://www.finextra.com/blogs/fullblog.aspx?blogid=4771 and the research by Celent and other analysts are highlighting the issues.
The reason the term is confusing is that everyone now claims to have such a solution and they put their spin on what one is, aligning their product with their interpretation. I am sure I do just the same. However there are some basics that can’t really
be denied:-
- A PSH needs to be a modern technology, standards based, SOA solution centralising the flow of payments from initiation to settlement
- Contains packaged payments functionality PLUS the ability to integrate existing assets and orchestrate ‘products’ easily using business rules not code
- Providing visibility (both internally and externally), management information and the right level of STP and manual interaction
- Reduces the connectivity spaghetti, making standards changes easier to manage and replacement of systems, components and services possible
To me a PSH does not have to do everything, but it needs to be able to easily (using standard tools) integrate the required services into the workflow, which could include a payments engine for volume or complex requirements. But it must have payments functionality,
not simply be a framework or a legacy engine with a few enhancements.
In reality a PSH will be different for each bank and is built using a solution that is based on modern SOA standards and incorporates integration technology and payments components in one package.