There are seemingly endless claims today about how vendors in our industry can accelerate, optimize and speed up various processes within your organization with the subliminal sentiments of ‘cheaper, better, faster’. But can they really take the high ground and truly own this claim?
In this blog, we set out a number of criteria you may want to bear in mind when you select your next vendor to support your payments transformation project, so you can truly optimize and accelerate your implementation in terms of speed and flexibility of adapting to change.
The argument against manual processes is clear - fat finger error, speed of process and review, population and re-population of information - but what hasn’t been so clearly set out is how far and how deep automation can be introduced into processes; indeed it's about automation from end-to-end. Automating only certain aspects of the chain introduces only a small percentage of efficiency - a drop in the automation ocean. Imagine the scope if you have automatic code generation as a result of configuration setting, automatic technical documentation production, and in fact a whole conveyor belt of automation.
Breaking this down further, orchestration by way of example, can be done by writing code. In the first instance however, a business analyst creates an agreed specification, then a developer must write the code; it must then be tested and re-tested and in about 8-9 months (or usually more) you have an excellent business application that performs the intended functions. But what happens if you turn this on its head and have automatic code generation and can use visual models to map one thing to another - dragging and dropping - rather than laboriously handcrafting code. The result: an easy to use application by both business analysts and developers that when mapped together can be executed at the click of a button to create the executable code or technical documentation you want. You have just shaved 6 months off your software development lifecycle, and in turn reduced your project budget.
Now that you now have end-to-end automation in your sights, what changes along this automated lifecycle need to be addressed?
Working with vendors that do not empower you to make these changes yourself and update at a business level, is counterproductive.
Typically, applications or systems are sold as one size fits all, but in fact it is increasingly the other way around - one size does not fit all and often doesn’t fit any at all. Financial message and payments formats change, standards evolve, business requirements develop, and if at every turn you have to rely on your vendor to make those changes, you’re looking at additional cost, time and due to complexity – project risk, added onto your projects. We firmly believe your vendor should offer tools that directly allow you, the customer, to make the changes you need in the timescale you require.
Integration may not instantly sound like an accelerator, however, easing integration both in terms of cost and resourcing remains one of the key stumbling blocks when it comes to quickly and simply interacting and communicating with both incoming and outgoing counterparties. Not to mention the fact that huge variations exist depending on how counterparties have developed their own proprietary message formats, and because industry variations adapt over time. Getting on top of the multitude (especially considering the huge number of counterparty relations) of message formats is an ever-increasingly complex challenge.
Payment hubs for instance, have a huge number of integration points to and from all the payment channels, ancillary processing systems and outgoing to clearing channels. Much akin to octopus tentacles, every point requires integration. If your systems cannot easily talk to each other, directly or through the hub, again cost, time and risk is introduced into your project. Furthermore, it isn’t just about issues into new systems or new technology but integration into legacy systems not necessarily designed to easily interact with new technology that causes some of the biggest issues. A classic example is to try implementing a real time payment system which is surrounded by legacy batch based applications.
Integration is typically very manual-intensive; coding is invariably done by hand and it is not uncommon that the coding designed and created by one individual is not easily amended by another, so if one departs the other cannot simply pick up, especially if the technical documentation is not kept up to date.
If you look at the whole picture - standards, variations of those standards, hard-coding performed by hand - and consider a change in this link, you are then looking at a very time consuming project on your hands. However, if you introduce features such as an out-of-the-box maintained library of message and payments standards ‘plugins’, automatic code generation, visualization, inbuilt testing and automated technical documentation, you suddenly have a much more efficient and streamlined business application development process.
A number of solutions in the market were created using old technology, technology that is now unsurprisingly considered to be outdated and arthritic. It is this outdated technology coupled with other legacy systems that can be barriers to optimization of processes.
In the payments space in particular, which is undergoing rapid change, payment processing systems weren’t designed for high speed payments and were often designed for pre-instant payment schemes. The digitalization we are seeing in this area calls for systems that are agile, reactive, resilient, scalable and optimized. However, even when faced with a legacy system, there is no need to throw it out and start from scratch - you can use clever technology that will help bring you into the digital payments age by forming an insulation layer around it, protecting your stable technology investment.
Contrary to the title of this section, unsavory facts are not ones to require, but ones to ensure you avoid with your vendors. For example, it is seemingly an accepted ‘unsavory’ fact that for every $1 you spend on payments transformation software you typically spend between $6-8 on implementing it when it comes to payment projects. The biggest headache in this regard is the integration of all the various specialist systems involved. We’d urge you to seek proof that your vendor can dramatically reduce and improve this ratio. There are without a doubt technologies available today that can achieve this.
Furthermore, rather than creating new parts or bolt-ons to older solutions, we’d suggest that your vendor provides you with the option to implement modular solutions that are easy to configure. This approach means maintenance costs can be reduced and managed by you internally.
Volante is in a strong position to capitalize on the need for financial institutions to transform their payment infrastructure projects. Features such as automation and configuration rather than coding will be critical when looking to maintain and increase business agility as new payment types are introduced and workflows need to adapt to them.